On 02/22/2012 09:18 AM, MAISONOBE Luc wrote:
Hi Thomas,
Hi Luc,
Yes. I hesitated to do that, as it could increase complexity. If this
occurs, it will occur once and then the capacity of the slot would be
increased to maxSlot + 1, and therefore will never be exceeded again.
What would you think about allocating the slots list with a capacity set
to maxSlots + 1 right from the constructor (it is currently allocated
with maxSlots). The alternative to avoid the additional entry implies
handling the entries shift by ourselves between the new entry and the
evicted one, taking care of which one is in the front since the shift is
either one index forward or backward.
yes, that's what I meant with increasing the initial capacity, but as
you pointed out yourself this is really a very very minor thing.
I understand you point. I considered the case where points are read from
a file (say a JPL ephemeris). In this case, it seemed better to create
bunch of points instead of one point only. However, this could be
handled at generator level and not at cache level. So the cache could
ask for just the next point, and the few generators that know it is more
efficient to read a whole set at once will do it. In fact, the API
already allows it since generators can provide more points than
requested, I simply did not fully used it.
ok this sounds good to me. I guess this will become more clearer once we
have experience with using such a cache for different objects /
scenarios. Do you plan btw. to make the caches configurable? The default
should be hidden / preconfigured for normal users, but it would be good
if one can change the defaults.
No, the Frame instances would still be built as they are now so they can
be linked together with a simple tree. The frames would contain a cache
for the transforms, which would implement TimeStamped.
yes, this makes more sense, I guess my thinking was to complicated.
I'm not sure yet if we should set up interpolation between transforms at
frame level and removing the specialized cache for lower level
computations like precession-nutation model, or if we should preserve
both levels (just like processors have level 1 and level 2 caches, and
sometimes even level 3).
I have no idea about that right now, but it would be good to have an
environment for performance testing different settings for different
scenarios.
What do you think about the way multithreading is handled with
ReentrantReadWriteLock at slots end entries level ? Does it seem
appropriate to you ? Did you find any design or implementation problem
on this specific topic ?
At first I was a bit musing about the slot mechanism, but when I
understand it correctly, your intention was to have fine grained control
over locking and eviction.
I have also looked into the multi-threading
part, but did not find a problem yet.
One important thing is that due to the current design of the cache, the
generator must itself be thread-safe, as it can happen that multiple
threads request entries from the generator. The javadoc states the
opposite, which is wrong imho.