Thanks for the link, but that kind of benchmark is not applicable here.
This article best describes our scenario:
http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html
We won't know the performance difference until after Javolution is
completely removed from the project - and here's why: When the
Javolution classes are loaded, their object pools are created. For
FastMap about 7 MB, and for FastList about 7MB. So we have these big
chunks of memory being held by Javolution that can't be used by other
objects. As a result, the garbage collector has to work harder to keep
memory available for other objects. When Javolution is removed
completely, then we recover that 14MB of memory and the garbage
collector is invoked less. Until that happens, I don't think we will see
any change.
-Adrian
On 4/2/2013 6:23 PM, Jacopo Cappellato wrote:
On Mar 31, 2013, at 11:09 AM, Adrian Crum <[email protected]>
wrote:
I created the branch to address the concerns in the previous discussion about
the performance impact of removing Javolution. In other words, the branch is
intended to be used with profilers before the changes are brought into the
trunk. I don't think there will be any adverse effects of removing Javolution -
because I understand how it did its 'magic' in the Java versions prior to 1.5.
So, I need to find a way to convince others before I would be willing to do the
work in the trunk.
One good reason for removing Javolution is that it doesn't seem that the
project is actively maintained anymore (even if I see that they are now working
on a new release, after several years).
By the way, when dealing with profiling/benchmarking you may find this useful:
http://blog.javabenchmark.org/2013/02/benchmarking-with-junitbenchmark.html
I am ready to commit some changes to disable selectively the specialpurpose components:
as we discussed we could even exclude them from the build/test process by default (the
idea is that maintaining them is "optional" i.e. it is ok to commit code to
framework/applications that breaks them but of course we are happy to accept
contributions to make specialpurpose component work)... in this way we could concentrate
on a smaller codebase (framework and applications).
Hmmm... I think I prefer removing Javolution from specialpurpose before we
remove specialpurpose.
It is fine; just let me clarify that I didn't mention to remove specialpurpose
from the trunk (only from the new release branch), only to disable some
components.
Jacopo
