[
https://issues.apache.org/jira/browse/CXF-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307997#comment-14307997
]
Alessio Soldano edited comment on CXF-6227 at 2/5/15 9:06 PM:
--------------------------------------------------------------
I've been running few tests on misc solutions for the issue of the time spent
on merging the 7 maps defining the message context in
MessageImpl#calcContextCache(), as discussed at
http://cxf.547215.n5.nabble.com/JAX-WS-client-performances-tp5753625p5753885.html
and following messages.
It looks like I can get ~ 2% performance improvements in my bench app by
computing an upper bound of the merged map size before actually creating it (of
that size) and calling putAll on it; the reason for the perf improvement is
most likely that the merged map does not have to be resized multple times when
running the putAll invocations.
I've also experimented another solution, which is giving basically the same
performances of the above one and is inspired by Dan's comment on the expected
small size of the maps. When computing the cache, I put the contents of all
maps (except the Message one) into String[][] (for the keys) and Object[][]
(for the values), which keep the memory usage low (compared to a new map). Any
'get' on that data structure is O( n ) which should be acceptable under the
assumption that the source maps are very small (I usually get ~ 25 entries
summing them all). The message map is kept as is and not copied, considering
it's usually the biggest one (~40-50 entries here) and it's what new context
properties end up into when calling setContextualProperty(String key, Object
v). This solution should trade a bit of 'get' performance with less memory
usage.
We could also consider yet another solution, with a context cache served by 2
maps, the Message one and the merge of all the others.
Quite frankly, I thought I would have got a more sensible performance
improvement, so unless I can find different scenarios requiring changes and/or
someone seconds the changes (or part of them, for instance one of the
implemented solutions only) in the attached patch file, I won't commit any of
the modifications described above.
was (Author: asoldano):
I've been running few tests on misc solutions for the issue of the time spent
on merging the 7 maps defining the message context in
MessageImpl#calcContextCache(), as discussed at
http://cxf.547215.n5.nabble.com/JAX-WS-client-performances-tp5753625p5753885.html
and following messages.
It looks like I can get ~ 2% performance improvements in my bench app by
computing an upper bound of the merged map size before actually creating it (of
that size) and calling putAll on it; the reason for the perf improvement is
most likely that the merged map does not have to be resized multple times when
running the putAll invocations.
I've also experimented another solution, which is giving basically the same
performances of the above one and is inspired by Dan's comment on the expected
small size of the maps. When computing the cache, I put the contents of all
maps (except the Message one) into String[][] (for the keys) and Object[][]
(for the values), which keep the memory usage low (compared to a new map). Any
'get' on that data structure is O(n) which should be acceptable under the
assumption that the source maps are very small (I usually get ~ 25 entries
summing them all). The message map is kept as is and not copied, considering
it's usually the biggest one (~40-50 entries here) and it's what new context
properties end up into when calling setContextualProperty(String key, Object
v). This solution should trade a bit of 'get' performance with less memory
usage.
We could also consider yet another solution, with a context cache served by 2
maps, the Message one and the merge of all the others.
Quite frankly, I thought I would have got a more sensible performance
improvement, so unless I can find different scenarios requiring changes and/or
someone seconds the changes (or part of them, for instance one of the
implemented solutions only) in the attached patch file, I won't commit any of
the modifications described above.
> JAX-WS client performance improvements
> --------------------------------------
>
> Key: CXF-6227
> URL: https://issues.apache.org/jira/browse/CXF-6227
> Project: CXF
> Issue Type: Improvement
> Components: Core
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: 3.0.4, 3.1.0
>
> Attachments: maps-patch.diff
>
>
> I've been running some performance tests and noticed few area in which we can
> apply optimizations.
> The most relevant issue is caused by
> https://bugs.openjdk.java.net/browse/JDK-8044726 and needs to be worked
> around while waiting for a fix in the JDK; more details at
> http://mail-archives.apache.org/mod_mbox/cxf-dev/201501.mbox/%3C54C7C78B.1010704%40redhat.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
