Re: [ jEdit-users ] jEdit with Javalution?

[Randall R S. <rs...@so...>]

Patrick,

On Monday 28 February 2005 13:43, Patrick Wright wrote:
> > I ran a test using my theorem prover, which makes very heavy use of
>
> java.util.Set as well as extensive use of java.util.Map. It was easy
>
>
> Randall
>
> Your tests are interesting, nice of you to share that.

Keep in mind that this was a crude test and the numbers are at best an 
approximation of the difference in behavior between the three 
collections implementations currently available to me. There's almost 
certainly some kind of systemic bias in the numbers and most likely the 
differences are underestimated. A proper test would involve profiling 
the test runs to isolate the amount of time spent in the collections 
code specifically and to try to get some kind of cost-to-operation 
ratios (e.g., cost per instantiation, cost per item addition, cost per 
membership test, etc.).

In this particular application, a theorem prover that employs tree 
search for which some key algorithms are non-deterministic, undesirable 
sensitivities to incidental implementation factors occur. Probably the 
biggest source of such differences originates in differing orders of 
instance return from iterators over the hashed data structures. So 
sometimes what you're measuring is a not really (or not entirely) the 
difference in the performance of the collection library, but rather the 
results of more or less fortuitous ordering of the tree search!


> If you look at http://javolution.org/doc/benchmark.html, there he has
> micro-benchmarked his stuff against Sun's. The upshot is that except
> for the text handling classes (Text and TextBuilder), his stuff is
> within spitting distance of the JDK's, even in his own benchmarks.
> And presumably, he would benchmark stuff that would show off where it
> is fastest (just guessing).

The Trove folks (actually, it's just one guy, I think) have done 
benchmarks, too. They're quite favorable, really, which is what led me 
to go through my code and replace all the java.util.XXX constructor 
calls with factory calls. In the end, I use the Sun implementations by 
default, but the ability to select either (now one of three) is still 
there.


> On the other hand, his benchmark show his text utilities as much
> faster than the JDK's. It would be interesting to compare it to a
> class like org.gjt.sp.jedit.buffer.ContentManager to see the
> difference. I just tried a simple test, but don't want to report
> something until I know how to use ContentManager properly (e.g. for
> best use)--also not sure if that is the proper one to test in any
> case.
>
> I wonder as well if he might have other feedback as far as your
> tests--why it was slower or close to the same as the JDKs.
>
> Anyway,
> Patrick


Assuming these alternate collections implementations are by some 
measures faster than the stock Sun implementations, my numbers strongly 
suggest that both Javolution and Trove have bought their improved Set 
and Map performance at the expense of more time-consuming instance 
set-up. In fact, for Trove, I've confirmed this through profiling and 
examination of its and Sun's code. So for an application like mine that 
uses most of its Set instances for such a brief time, the net result of 
these techniques is not optimization, but "pessimization," if you will. 
Unfortunately, for Javolution this factor is much more pronounced than 
it is for Trove.


Randall Schulz