[ 
https://issues.apache.org/jira/browse/IGNITE-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15071248#comment-15071248
 ] 

Vladimir Ozerov edited comment on IGNITE-2265 at 12/24/15 9:11 PM:
-------------------------------------------------------------------

Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspots revealed by profiler. Some atomics are 
located inside our cache futures which are created on virually any cache 
operation. And in a simple benchmark with distributed cache GET, these Atomics* 
are responsible for 2-3% of all heap allocations  We can easily get rid of 
these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.


was (Author: vozerov):
Andrey,

You are asking tough questions :-) It is hard to reason whether particular 
microoptimziation will give any observable benefit or not. 

Basically, I am trying to find places which could speedup the product. Clearly, 
there are lot of them. So for now I am looking for suspicious code pieces which 
are both a) easy to improve; b) have good chances to increase overall 
performance.
To identify them I simply run base scenarios like GET/PUT and see profiler 
results in terms of hot execution paths and memory allocations. 

Atomic* variables is one of the hotspot which were revealed by profiler. Some 
atomics are located inside our cache futures which are created on virually any 
cache operation. And in a simple benchmark with distributed cache GET, these 
Atomics* are responsible for 2-3% of all heap allocations  We can easily get 
rid of these Atomics and decrease memory pressure. 

2-3% is not a big number when considered separately. But if more similar 
optimizations are applied, we could reduce memory pressure in common scenarios 
by about 20-25% with minimal efforts. I log such potentially promising finding 
as subtask to the parent ticket IGNITE-2232.

> Replace Atomic* variables with field updaters.
> ----------------------------------------------
>
>                 Key: IGNITE-2265
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2265
>             Project: Ignite
>          Issue Type: Sub-task
>          Components: general
>    Affects Versions: ignite-1.4
>            Reporter: Vladimir Ozerov
>            Assignee: Vladimir Ozerov
>             Fix For: 1.6
>
>
> Field updaters must be used instaed of the following classes:
> 1) AtomicInteger
> 2) AtomicLong
> 3) AtomicReference
> 4) If AtomicBoolean is met in some hot spaces, it must be replaced with (int 
> + updater) pair. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to