commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Neidhart (JIRA)" <>
Subject [jira] [Commented] (IO-468) Avoid allocating memory for method internal buffers, use threadlocal memory instead
Date Sun, 08 Feb 2015 19:25:34 GMT


Thomas Neidhart commented on IO-468:

The drawbacks of ThreadLocals are that they might leak memory in web application server, see
the blog here for example:

As a developer of a general-purpose library one has to keep exactly an eye on that: general
purpose use. We can not optimize for one specific use-case, i.e. maximum performance, when
the utility method is mainly used in total different setups.

Furthermore, there is a way to get *maximum* performance: not using a ThreadLocal but providing
a local byte array when calling the method. This should be faster than going via a ThreadLocal.
Did you test this in your performance test? Also, the buffer size will highly depend on the
use-case. To get maximum performance you will want to adjust the buffer size, which is not
possible with the ThreadLocal solution either.

I can understand when someone is pissed because his performance patch is not accepted, but
if you take a step back you will realize that it really does not make any sense here.

> 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,
>   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