[
https://issues.apache.org/jira/browse/IGNITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2721.
-------------------------------------
Resolution: Duplicate
> Optimize ATOMIC cache request/responses.
> ----------------------------------------
>
> Key: IGNITE-2721
> URL: https://issues.apache.org/jira/browse/IGNITE-2721
> Project: Ignite
> Issue Type: Task
> Components: cache
> Affects Versions: 1.5.0.final
> Reporter: Vladimir Ozerov
> Priority: Critical
> Labels: performance
> Fix For: 1.6
>
>
> Our request/responses for ATOMIC cache has lots of fields which are normally
> unused.
> To give an idea on possible optimizations lets look closely on
> GridNearAtomicUpdateRequest:
> * {{futVer}} - could be converted to int
> * {{syncMode}} - why do we pass it? Can it be derived from cache config?
> * {{op}} - can it be derived form request?
> * Entry processors and invoke arguments - can be moved to extras, or separate
> request class can be created for them.
> * Conflict data - usually null, must be moved to extras
> * Expiry policy - must be moved to extras.
> * {{filter}} - only one filter is ever passed - when we need to compare
> existing value. Lets pass the value instead!
> * Lots of flags - can be written as a single byte. Though, it's priority is
> not so high.
> * {{topVer}} - could easily be inlined to save allocations and network
> traffic.
> As a result of this investigation we must create a list of optimizations to
> be performed and prioritize them. Then we should implement them one by one,
> keeping them merged in a separate branch (not master!) until we are sure that
> we did everything we can.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
