Re: Eclipse 3.6..uppressWarnings changes

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Sat Apr 10 2010 - 04:16:07 EDT

  • Next message: Dov Rosenberg: "JDBC4 Support?"

    On 08/04/2010, at 6:27 AM, Mike Schrag wrote:

    >>> Cocoa SWT just can't seem to get it all together on the performance front.
    >> Out of interest; do you know what the issue is there? Are they using GC in the Objective-C side or reference counting?
    > it's not clear .. there are several bugs that explore wtf is going on:
    >
    > https://bugs.eclipse.org/bugs/show_bug.cgi?id=285175

    I believe the situation with the above bug has improved quite a bit since 3.5.0. I've been using 3.5.x (3.5.2 atm) for quite some time and the original 3.5.0 problem where it would take ages to open new files (or just spin forever if you tried to open a reasonable sized selection via F3) is no longer a problem - at least for my day to day work (and perhaps for the average dev. It may still, of course, be optimised further but it ain't anywhere near as noticeably bad as was.

    > https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229
    >
    > are a couple of the nastiest ones, and i SUSPECT fixing these will fix a lot of the underlying problem.

    It certainly could be much quicker - but I've never found myself scrolling via the cursor from the top of a file to the bottom very often ;-). But maybe I've been putting up with a crappy situation for too long, not being bothered to go through the hassle of setting up my env again. So here goes...

    Java File with 1253 lines, starting with cursor at the top and holding down the arrow key:

    Mac OS X 10.6.3, 2.6 Ghz Intel Core 2 Duo, 4 Gb Ram:
    - Eclipse 3.5.2 Cocoa/64 - 100 seconds! Ouch. (*)
    - Xcode on Mac: ~42 seconds.
    - TextEdit on Mac: ~44 seconds
    - TextMate on Mac: ~42 seconds
    - emacs: ~42 seconds
    - Eclipse 3.5.2 Carbon/32: ~43 seconds.

    Ubuntu 64 via Virtual Box on Mac
    - Eclipse 3.5.2 64/Linux: ~43 seconds!
    - gedit: 51 seconds

    * Admittedly not a fair comparison as I've not loaded up the other Eclipse installs with anything other than what they came with.

    > the entire control stack is wrapped in java, though, which means going in and out of native code a LOT. it's possible that just the model for this is just going to be very hard to optimize. there's a reason that carbon is the preferred implementation for systems like SWT ... it's ust way easier to do the plumbing in the carbon model than the cocoa model. look at the stack depth of the jprofiler profiling run i did on one of those bugs. it's insane. it's like 150 frames deep to repaint during scroll.
    >
    > there does appear to also be a bunch of duplicate work going on, but it doesn't seem to account for enough time to explain the performance.
    >
    > ms

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Sat Apr 10 2010 - 04:17:18 EDT