Re: [Pydev-code] [Pydev-cvs] org.python.pydev.core/src/org/python/pydev/core/structure FastStringBuffer.java, NONE, 1.1

[Fabio Z. <fa...@gm...>]

Hello Radim,

> I noticed this interesting commit and want to ask:
>
> Why do you think StringBuffer performance is a problem (for PyDev)?
> Why do you think this FastStringBuffer is better?
> Did you consider to use StringBuilder?
> What are result of your measurements?

StringBuilder is not an option because pydev needs to support java 1.4
/ Pydev does lot's of string concatenations in a good number of cases.

The results here are on java 1.5... the microbenchmark is committed at
http://pydev.cvs.sourceforge.net/pydev/org.python.pydev.core/tests/org/python/pydev/core/structure/FastStringBufferTest.java?view=markup
(although the benchmark part is commented out).

It's optimized for: creating a string, filling it, calling clear() and
then reusing it again (which is what the benchmark does).

In the microbenchmark it runs at 0.4 times the time the actual
StringBuffer runs in java 1.5.

Basically on that case it saves a couple of calls to a super.append
method, does not check for null strings and has no len check (so,
basically it does less checking to gain speed -- it'll still throw
exceptions, but not exceptions as given by a StringBuffer, only on
invalid array accesses). Also, a clear() method and deleteLast() were
added which are also much faster (basically, they just change the
marked size of the buffer -- pydev relies on test-cases instead of
having checks for abnormal cases, so, I'm not sure I'd recommend it as
a general case StringBuffer).

> Few things to note: be carefull to do enough run to avoid results
> skewed by interpreted runs before JIT compiles the code.
>
> Look at the difference between server and client VM (at server VM I do
> not see any difference).
>
> Check various JDKs - StringBuffer can be slower on JDK 1.5 but gets to
> comparable level on JDK6 with its biased locking.
>
> Generally it can happen that JIT will optimize your code completely
> and remove it ;-) It is really hard to write correct microbenchmark
> for Java code.

Yeap, I've taken that into account, but as you never know which jdk
the client will be using, even if in the end it only significantly
does a change for some java vms, it's worth it -- if it does not get
slower on another version... but I'm pretty confident that this will
not happen in this case -- it's amazing that some versions of MacOS
are bounded to a JDK 1.4 and you can't update it (at least that's the
complain I got a lot when pydev started to support only java 1.5 --
so, 1.4 support was restored).

> I do not see where you saved allocations/GC (javadoc says that this
> new class is more effective). Even if you do - GC of an object dying
> in eden is not a problem. Only surviving objects are important.

You're right, it does not save allocations (I'll update the docs). The
idea is to save allocations on the case where it says that should be
used in the docs: create the buffer, do lot's of things then call
clear() and do things again... so, loops should only allocate one and
rely on cler() instead of creating a new buffer to save allocations
(in that commit a number of places were updated for that case). So,
one of the advantages of that case is that I also know which places
I've re-reviewed for that case (basically, if it's not using that
version of the buffer it's not reviewed for that case -- although some
reviewed places kept on using StringBuffer because of features that
won't be added to that version).

Cheers,

Fabio