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

[Radim K. <ra...@ku...>]

That's great explanation! Thanks. I'll add a few comments.

On Sun, Jun 15, 2008 at 5:37 AM, Fabio Zadrozny <fa...@gm...> wrote:
> 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.
>
Almost every Java program does so this is indeed a common hot spot.

> 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.
>
I do not any actual numbers in the log or test source itself and my
runs showed smaller improvement. This is not a problem. Hopefully
there is some task where this change maps to improved perceived
performance - a user action that is noticeably faster.

Re reusing: object allocation is basically bump up a pointer and
return it. Only when a thread local allocation buffer is exhausted
this needs to get a new slice of memory (your microbenchmark is not
covering any threading).

> 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).
>
Generaly most of these optimization can be done in HotSpot and some of
them really are. Aggressive inlining is common, then you can analyze
flow and avoid null check. Array bounds checking can be simpler with
loop unrolling. It takes a while but current compilers are really
smart.

>> 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).
>
The opposite way is: just by upgrading to JDK6 users get a nice
benefit of a performance on the same level as you current have and
there is no need for code changes.

If you really have a lot of users running JDK1.4 this is a valid use
case (especially if they use pydev ext). Though these folks are in a
really troubled situation. Now Apple released Java6 and I wonder how
long they will support 1.4 an old systems. Well that's a strange world
of Java on Mac.

Regards,
Radim

>> 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
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>