ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@gridgain.com>
Subject Re: GridConcurrentFactory.CONCURRENCY_LEVEL
Date Wed, 11 Mar 2015 12:25:52 GMT
I removed the iteration and committed it to sprint-2.

--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com

2015-03-11 1:37 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> Sergey,
>
> I think the default concurrency level should be the number of available
> cores times 2. On top of that, I would also look at why GridTaskProcessor
> needs to iterate over list of tasks on each submit... is it really
> necessary?
>
> D.
>
> On Tue, Mar 10, 2015 at 6:29 AM, Yakov Zhdanov <yzhdanov@gridgain.com>
> wrote:
>
> > I agree, this makes iterations over map much longer.
> >
> > Please create ticket in jira and remove the factory and run benchmarks
> > after that.
> >
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2015-03-08 21:45 GMT+03:00 Sergey Evdokimov <sevdokimov@gridgain.com>:
> >
> > > Hello,
> > >
> > > Why we have so huge concurrency level for concurrent hash maps created
> by
> > > GridConcurrentFactory.newMap() ? By default concurrency level is 256,
> > does
> > > we expect that 265 thread will update the map *at same time*? Huge
> > > concurrency level increases iteration time.
> > > When I set concurrency level to jvm default value (16) my benchmark
> > became
> > > 73% faster (23000 operation/sec vs 40000 operation/sec). My benchmark
> > just
> > > executes simple job on local node. GridTaskProcessor iterates over
> > > GridTaskProcessor#tasks on each task submit. Although
> > > GridTaskProcessor#tasks is empty iteration get a lot of time.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message