commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <>
Subject [jira] [Commented] (IO-468) Avoid allocating memory for method internal buffers, use threadlocal memory instead
Date Mon, 09 Feb 2015 00:45:34 GMT


Sebb commented on IO-468:

I think the benchmark is not really the main issue here, although it will be interesting to
know whether or not ThreadLocal is quicker than memory allocation, and for what buffer sizes.
Though of course that may change with different JVMs.

The point is that the patch has a side effect, which is that memory is held for longer periods
than may be necessary.

Also, it's not that allocation of the buffer is particularly slow, so even if ThreadLocal
is twice as fast, it's not going to make much difference to the average app.
But it may make some apps with multiple threads use much more memory.

If the patch speeded up the code for all conditions, and had no side effects, that would be

But that is not the case here.

Furthermore, an app that does rely heavily on the copy methods can provide the appropriate
buffers in order to gain a performance benefit.
But that will need to be tested in the context of the app itself to know whether the trade-off
between memory usage and allocation speed is worth it or not.

I am against changing the existing methods.
Though I would be OK with adding Javadoc to note that the convenience methods which provide
their own buffers may in some cases be less efficient than using buffers provided by the application.

> Avoid allocating memory for method internal buffers, use threadlocal memory instead
> -----------------------------------------------------------------------------------
>                 Key: IO-468
>                 URL:
>             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:, 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, 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

This message was sent by Atlassian JIRA

View raw message