Hi Laurent,
On 6/22/2015 9:39 AM, Laurent Bourgès wrote:
I thought you wanted to remove completely initial arrays to simplify the
code and rely on the cache only:
that's why I tested the impact of such solution and I set initial arrays
to [0] to force the cache usage: get/put.
I was saying to eliminate "special handling" of the initial arrays. In
other words, all arrays should come from the cache and so there would
never be any tests for "is this array supposed to be in the cache?".
So you propose to enlarge the memory footprint consumed by initial arrays.
The bucket #0 size is for now 4096 (16K for int/float arrays) and 32768
(32K) for dirty bytes.
So, it looks like there is a large jump between initial array sizes and
the first bucket?
I didn't read through all of your analysis as I didn't understand all of
your shorthand. What is the current starting size of all arrays
compared to the starting size we would have if we forced all growable
arrays to use their bucket#0 size?
One thought is if the initial memory cost gets too large to have all
arrays start with bucket#0 sizes, we could also bake the size of the
initial arrays into the cache object itself, so it would have the
concept of an initial size and a number of buckets of growable sizes.
(Or simply a list of sizes and the first size could be much smaller than
the rest). At least then the "special size case" would be a part of the
contract rather than an assumption between the implementation and its uses.
In about a week I might have some free time to prototype an example of
what I envision for managing growable arrays. Some example code might
be more useful as a starting point for these discussions...
...jim
