[
https://issues.apache.org/jira/browse/GEODE-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094918#comment-17094918
]
ASF GitHub Bot commented on GEODE-6636:
---------------------------------------
onichols-pivotal commented on pull request #4234:
URL: https://github.com/apache/geode/pull/4234#issuecomment-620900280
Here's a summary of the benchmark results from the above run (positive
number = improvement)
-3.6% Benchmark_base PartitionedFunctionExecutionBenchmark
+2.1% Benchmark_base PartitionedFunctionExecutionWithArgumentsBenchmark
-5.1% Benchmark_base PartitionedFunctionExecutionWithFiltersBenchmark
-1.4% Benchmark_base PartitionedGetBenchmark
+5.9% Benchmark_base PartitionedIndexedQueryBenchmark
+4.3% Benchmark_base PartitionedNonIndexedQueryBenchmark
+1.2% Benchmark_base PartitionedPutAllBenchmark
-0.6% Benchmark_base PartitionedPutBenchmark
+0.1% Benchmark_base ReplicatedFunctionExecutionBenchmark
-1.2% Benchmark_base ReplicatedFunctionExecutionWithArgumentsBenchmark
-1.2% Benchmark_base ReplicatedFunctionExecutionWithFiltersBenchmark
-0.8% Benchmark_base ReplicatedGetBenchmark
-2.4% Benchmark_base ReplicatedIndexedQueryBenchmark
+7.1% Benchmark_base ReplicatedNonIndexedQueryBenchmark
+0.7% Benchmark_base ReplicatedPutAllBenchmark
+0.3% Benchmark_base ReplicatedPutBenchmark
-1.3% Benchmark_base PartitionedFunctionExecutionWithFiltersBenchmark
-3.3% Benchmark_with_ssl PartitionedGetBenchmark
-1.2% Benchmark_with_ssl PartitionedPutBenchmark
-0.2% Benchmark_with_ssl ReplicatedGetBenchmark
+1.4% Benchmark_with_ssl ReplicatedPutBenchmark
-5.8% Benchmark_with_security_manager PartitionedFunctionExecutionBenchmark
+2.2% Benchmark_with_security_manager
PartitionedFunctionExecutionWithArgumentsBenchmark
+1.9% Benchmark_with_security_manager
PartitionedFunctionExecutionWithFiltersBenchmark
-2.0% Benchmark_with_security_manager PartitionedGetBenchmark
-0.1% Benchmark_with_security_manager PartitionedIndexedQueryBenchmark
-3.8% Benchmark_with_security_manager PartitionedNonIndexedQueryBenchmark
+0.7% Benchmark_with_security_manager PartitionedPutAllBenchmark
-1.4% Benchmark_with_security_manager PartitionedPutBenchmark
-4.1% Benchmark_with_security_manager PartitionedFunctionExecutionBenchmark
@pivotal-jbarrett does this satisfy your request for changes?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Buffers.acquireBuffer is not optimal
> ------------------------------------
>
> Key: GEODE-6636
> URL: https://issues.apache.org/jira/browse/GEODE-6636
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Assignee: Mario Ivanac
> Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> org.apache.geode.internal.net.Buffers.acquireBuffer takes buffers out of a
> ConcurrentLinkedQueue. If the buffer is too small then it adds it back to the
> queue and adds it to an IdentityHashMap. The map is just to detect if we have
> looped around and found one we added to the map in a previous iteration.
> A more efficient way to do this, which will only remove things from the queue
> that we will either throw away or use and return later, and which gets rid of
> the map, is to use ConcurrentLinkedQueue.remove(Object). You can see an
> example of this by looking at:
> AvailableConnectionManager.EqualsWithPredicate. The predicate to use with
> acquireBuffer is that the soft reference is null or that the capacity of the
> referenced buffer is large enough. If you remove one because the reference is
> null then you need to call remove(Object) again (after decrementing the
> correct stat) since all you did was find one that had been garbage collected.
> You want to keep the predicate as cheap as possible since it is called in the
> "compare-and-set" spin loop. The more you do in the predicate, the more
> likely a concurrent thread will take that buffer and you will need to spin
> around and try again.
> I was surprised when running a benchmark under the profiler to see operations
> on this IdentityHashMap show up. The benchmark was doing pr puts of all the
> same size so I would have thought all these direct buffers would be the same.
> I think it would be worth understanding what sizes of buffers will be
> requested by acquireBuffer and how often they will be acquired and returned.
> If different sizes is a normal use case then it probably would make sense to
> have more than one queue. If we could go to a queue knowing that if it has a
> buffer in it that it meets are desired size. The geode off-heap free list
> implementation does this and only the largest allocations need to search
> through a free list that has items in it that exceed a max size. Every other
> free list is found quickly be using the requested size to index an array of
> free lists, which only contain items of that size.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
