4 ms·

Had no idea Cyberduck is written in Java. If only all Java desktop applications are like this.

• albertzeyer 16y ago
  Oh, me neither! I really had to check this out. The main point seems to be: They don't use any of the Java GUI frameworks. They instead use some Cocoa bindings. See here: http://trac.cyberduck.ch/browser/trunk/source/ch/cyberduck/ui/cocoa http://trac.cyberduck.ch/browser/trunk/source/ch/cyberduck/u...
• rimantas 16y ago
  I use SmartSVN, wouldn't call it ugly.
  • albertzeyer 16y ago
    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.