On Fri, Nov 6, 2020 at 6:13 AM David Rowley <dgrowle...@gmail.com> wrote:
> On Mon, 2 Nov 2020 at 20:43, David Rowley <dgrowle...@gmail.com> wrote: > > > > On Tue, 20 Oct 2020 at 22:30, David Rowley <dgrowle...@gmail.com> wrote: > > I did some further tests this time with some tuple deforming. Again, > > it does seem that v9 is slower than v8. > > > > Graphs attached > > > > Looking at profiles, I don't really see any obvious reason as to why > > this is. I'm very much inclined to just pursue the v8 patch (separate > > Result Cache node) and just drop the v9 idea altogether. > > Nobody raised any objections, so I'll start taking a more serious look > at the v8 version (the patch with the separate Result Cache node). > > One thing that I had planned to come back to about now is the name > "Result Cache". I admit to not thinking for too long on the best name > and always thought it was something to come back to later when there's > some actual code to debate a better name for. "Result Cache" was > always a bit of a placeholder name. > > Some other names that I'd thought of were: > > "MRU Hash" > "MRU Cache" > "Parameterized Tuple Cache" (bit long) > "Parameterized Cache" > "Parameterized MRU Cache" > > I think "Tuple Cache" would be OK which means it is a cache for tuples. Telling MRU/LRU would be too internal for an end user and "Parameterized" looks redundant given that we have said "Cache Key" just below the node name. Just my $0.01. -- Best Regards Andy Fan
