5 ms·

But this seems to be AWT. And the GUI just doesn't feel as snappy as native Cocoa. Actually, I wonder why that is. I always thought that it is Java itself whic

But this seems to be AWT. And the GUI just doesn't feel as snappy as native Cocoa. Actually, I wonder why that is. I always thought that it is Java itself which makes Java applications feel slow. But I haven't noticed this in Cyberduck. So maybe it is just AWT. I wonder why that might be. Maybe because AWT does all the drawing itself, which is much slower compared to the native toolkit?

riffraff 16y ago
many SWT apps, using native look and feel, still feel slowish (think azureus/vuze if not eclipse). Some AWT apps are perfectly snappy e.g. jedit opens a file faster than macvim on my box. My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding. In turn, this is probably a byproduct of the java platform/language (abuse threads cause they are easier than an event loop, abuse locking cause synchronized is more obvious than util.concurrent, avoid thinking of memory management cause you have a GC, do not pay attention to proper data structures cause you can get away with builtin collections etc)
- stcredzero 16y ago
  do not pay attention to proper data structures cause you can get away with builtin collections etc Specific examples from your experience?
  - riffraff 16y ago
    code I wrote myself :) First one I think of (cause I redid it today, in ruby :) is: you need to keep a list of lines you already processed in a large log analysis. I'd just use a Set (which is a hash underneath) and get done, although I'd have saved a bunch of overhead (memory allocations, gc pressure) using a bloom filter.
    - stcredzero 16y ago
      Examples where the "extra overhead" caused an actual problem?
      - riffraff 16y ago
        the one I just wrote you about
        stcredzero 16y ago
        What problem did that specific bit of GC pressure cause you? (I'm doing "5 whys" in reverse. Otherwise known as "The Socratic Method.")
        riffraff 16y ago
        sorry I thought I replied yesterday but apparently my comment got lost. Using a (hash)set instead of a bloom filter caused memory usage to explode, which in turn led to memory thrashing/swapping which in turn led to slow processing times. The rest of the code runs in constant time (well, linear in the size of the item, with num(items) >> size(items[n]) ) and it did work fine for smaller inputs.
        stcredzero 16y ago
        How much slower? Just how much wall clock time did you lose?
        riffraff 16y ago
        hard to estimate I'm sorry. The first naive implementation had been running for more than 15 minutes before I thought it as too much and killed it. Rewrote version run all in about 5.
      - riffraff 16y ago
        A a few more gigabytes of memory allocated, consequent swapping and slow processing

riffraff 16y ago

many SWT apps, using native look and feel, still feel slowish (think azureus/vuze if not eclipse). Some AWT apps are perfectly snappy e.g. jedit opens a file faster than macvim on my box. My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding. In turn, this is probably a byproduct of the java platform/language (abuse threads cause they are easier than an event loop, abuse locking cause synchronized is more obvious than util.concurrent, avoid thinking of memory management cause you have a GC, do not pay attention to proper data structures cause you can get away with builtin collections etc)

stcredzero 16y ago
do not pay attention to proper data structures cause you can get away with builtin collections etc Specific examples from your experience?
- riffraff 16y ago
  code I wrote myself :) First one I think of (cause I redid it today, in ruby :) is: you need to keep a list of lines you already processed in a large log analysis. I'd just use a Set (which is a hash underneath) and get done, although I'd have saved a bunch of overhead (memory allocations, gc pressure) using a bloom filter.
  - stcredzero 16y ago
    Examples where the "extra overhead" caused an actual problem?
    - riffraff 16y ago
      the one I just wrote you about
      - stcredzero 16y ago
        What problem did that specific bit of GC pressure cause you? (I'm doing "5 whys" in reverse. Otherwise known as "The Socratic Method.")
        riffraff 16y ago
        sorry I thought I replied yesterday but apparently my comment got lost. Using a (hash)set instead of a bloom filter caused memory usage to explode, which in turn led to memory thrashing/swapping which in turn led to slow processing times. The rest of the code runs in constant time (well, linear in the size of the item, with num(items) >> size(items[n]) ) and it did work fine for smaller inputs.
        stcredzero 16y ago
        How much slower? Just how much wall clock time did you lose?
        riffraff 16y ago
        hard to estimate I'm sorry. The first naive implementation had been running for more than 15 minutes before I thought it as too much and killed it. Rewrote version run all in about 5.
    - riffraff 16y ago
      A a few more gigabytes of memory allocated, consequent swapping and slow processing