Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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)



do not pay attention to proper data structures cause you can get away with builtin collections etc

Specific examples from your experience?


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.


Examples where the "extra overhead" caused an actual problem?


A a few more gigabytes of memory allocated, consequent swapping and slow processing


the one I just wrote you about


What problem did that specific bit of GC pressure cause you? (I'm doing "5 whys" in reverse. Otherwise known as "The Socratic Method.")


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.


How much slower? Just how much wall clock time did you lose?


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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: