[
https://issues.apache.org/jira/browse/IO-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325626#comment-14325626
]
Thomas Neidhart commented on IO-468:
------------------------------------
The Error is the score inside the 99.9% confidence interval.
It is indeed surprising that the ThreadLocal variant is sometimes faster, but I
had the same with my own (simpler) benchmark setup. It probably shows the
general instability of such micro-benchmarks. The memory array test is indeed
not very meaningful as it does not really reflect normal usage, but it is
useful as stress test for the cost of array allocation as we will not run into
general IO blocking issues.
In my previous benchmark I also compared the common use-case of copying a file
into memory, where the differences quickly disappeared as expected (the cost of
the allocation is negligible to the cost of the stream copying from harddisk).
Testing different buffer sizes would also makes sense, but at some point we
have to stop as we have already proven that micro-optimization in this case
does not make much sense.
> Avoid allocating memory for method internal buffers, use threadlocal memory
> instead
> -----------------------------------------------------------------------------------
>
> Key: IO-468
> URL: https://issues.apache.org/jira/browse/IO-468
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 2.4
> Environment: all environments
> Reporter: Bernd Hopp
> Priority: Minor
> Labels: newbie, performance
> Fix For: 2.5
>
> Attachments: PerfTest.java, micro-benchmark.zip,
> monitoring_with_threadlocals.png, monitoring_without_threadlocals.png,
> performancetest.ods, performancetest_weakreference.ods
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> In a lot of places, we allocate new buffers dynamically via new byte[]. This
> is a performance drawback since many of these allocations could be avoided if
> we would use threadlocal buffers that can be reused. For example, consider
> the following code from IOUtils.java, ln 2177:
> return copyLarge(input, output, inputOffset, length, new
> byte[DEFAULT_BUFFER_SIZE]);
> This code allocates new memory for every copy-process, that is not used
> outside of the method and could easily and safely reused, as long as is is
> thread-local. So instead of allocating new memory, a new utility-class could
> provide a thread-local bytearray like this:
> byte[] buffer = ThreadLocalByteArray.ofSize(DEFAULT_BUFFER_SIZE);
> return copyLarge(input, output, inputOffset, length, buffer);
> I have not measured the performance-benefits yet, but I would expect them to
> be significant, especially when the streams itself are not the performance
> bottleneck.
> Git PR is at https://github.com/apache/commons-io/pull/6/files
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
