All of optimizations applied to futures so far were extremely effective. Ignite can create different number of futures per operation depending on context. Multiple this by ops/sec.. This is probably one of the most intensively instantiated (and therefore GCed) object. Internal futures is very sensitive part of the system and should be 100% effective.
As far as public API, anyone uses org.apache.ignite.lang.IgniteFuture#startTime or org.apache.ignite.lang.IgniteFuture#duration? --Yakov 2016-01-15 1:20 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > Really hard to believe that removing 16 bytes in futures gives 5% of > performance. Yakov, are you certain about this? > > If this turns out to be true, let’s see if we can slim down the futures > used internally, without breaking the public API. > > D. > > On Thu, Jan 14, 2016 at 8:36 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > +1 > > > > BTW, corresponding ticket already exists. You can find it under umbrella > > ticket IGNITE-2232 > > 14 янв. 2016 г. 18:40 пользователь "Yakov Zhdanov" <yzhda...@apache.org> > > написал: > > > > > Guys, > > > > > > We have startTime(), duration() and endTime() methods which have > several > > > usages each along internals of the project, but to support these > methods > > we > > > have 2 long fields in GridFutureAdapter which gives us 16 bytes. > > > > > > Other fields - res (reference 8 bytes at max), ignoreInterrupts > (boolean > > 1 > > > byte) and resFlag (byte 1 byte) = 10 bytes > > > > > > I did quick tests and I see that removing these fields (i.e. making > each > > > future 16 bytes thinner) can give us 5-6% in performance results. > > > > > > I want to deprecate startTime(), duration() and endTime() and > therefore > > > deprecate corresponding methods in IgniteFuture. > > > > > > Thoughts? > > > > > > --Yakov > > > > > >
