Linked by Eugenia Loli-Queru on Wed 22nd Mar 2006 18:08 UTC
"Newer software does try to be sexier by doing flashy things such as the talking paperclip. This causes a tendency for the software to bloat to the point of saturation, i.e. until it performs at barely acceptable speeds. But application programming seems to get worse with faster processors. Even with more memory, faster disks and multiple CPUs, your average web application runs slower. Is it possible that the faster hardware has made us worse programmers?"
Thread beginning with comment 106836
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:
2005-07-06
One of the things that seems to be very influential on the memory hogging that is introduced by new programs is the *bad* way that memory gets allocated, and the wasteful way that memory is used.
Indeed. I see a lot of heap allocation used when static or stack allocation would suffice. I've seen many Java classes where fields are declared and objects allocated for every instance, when only one instance is ever needed (should be declared static). Also, I've seen many classes where fields are declared which should be locals. It all adds up. (The code I'm talking about is by fellow students so I don't know if such amaturish practices are more widespread). Got any more examples yourself? I'd like to catalogue these "memory abuses" for fun & profit ;-)
I have written an allocator with essentially zero overhead per object (they are packed together like an array) with only a small overhead per page (20 bytes I think). Of course this requires that you have seperate pages for different object sizes, but it's a nice trade-off and works well.
Think about the overhead you pay with java.lang.Object for small objects. If you have, say, an object with two int fields, 8 bytes, and the overhead was 8 bytes (hypothetical, I don't know), you've just doubled your memory usage! People don't consider these things.
For example, it seems to me that anyone who writes a Java app manages to do this is such a p*ss poor way that the garbage collector can't reclaim memory as it should (due to referenses never used again).
What would you suggest the GC do though? It can't leave dangling references. Java supports weak pointers (see java.lang.ref) if that's the behaviour you need (very useful for object caching).