Re: [Orekit Developers] TimeStampedCache Improvements

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Evan Ward <evan.ward@nrl.navy.mil> a écrit :

> Hi,

Hi Evan,

> I've noticed that the current implementation of TimeStampedCache (TSC)
> can still be a performance issue when it is highly contended. I've also
> found the getNeighbors(date) method to be very valuable, even when I'm
> not expecting multiple threads. So I propose refactoring the TSC to an
> interface so different implementations can be used, depending on the
> context. The interface would have 4 methods:
>
>   List<T> getNeighbors(final AbsoluteDate central) throws
> IllegalArgumentException; (Or TSCException)
>   int getNeighborsSize();
>   T getEarliest() throws IllegalStateException;
>   T getLatest() throws IllegalStateException;

This seems good.

> Besides the existing implementation I have an immutable implementation
> that is lock free. The immutable version can improve performance where
> all the data stored in memory. (~2x faster sequential, ~40x faster
> concurrent) I think AbstractEOPHistory, Ephemeris, and UTCScale could
> all use the immutable version.

Yes.

> User classes could also use the
> lighter-weight cache for interpolating their data. (I had some
> difficulty figuring out how AbstractEOPHistory is used. Correct me if
> I'm wrong, I think it is only "written" in FramesFactory when it is
> created and then only "read" after that.)

You are right. We fill this only once when we load the data using the  
DataLoader/DataProvider mechanism.

> What do you think of this refactoring? It would also open the
> possibility for a mutable cache based on a lock free ConcurrentMap.

+1 to do it.

best regards,
Luc

> Regards,
> Evan



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.