It's been a while since I posted last. My latest project deals with manipulating images using pixel shaders. I have a few other side things that I'm working on too... but for the most part they are all on the "back burner": I plan to work on them eventually, but they aren't getting anywhere at the moment.

I've been reading a bit on garbage collection schemes. Performance is a big issue for me, and the worst thing that can happen is that your program hard faults: portions of either its code or data have been paged out to the disk and need to be paged back in to memory. Paging is the number one performance killer on today's desktop systems. Throwing more ram at the problem is one solution, but writing more memory-efficient code is a better solution. I'm very curious to see what kinds of memory usage patterns common programs have, I just need to find (or write) a good tool to help visualize memory usage.

Qt is a great library, and I use it in almost all my GUI-based projects. That's not to say it's perfect, though. I run into some problems using it pretty frequently. Usually it is nothing major, but bugs are always frustrating. I should look into some Qt-specific forums or mailing lists to see if I can get some community support on some of these issues.

A lot of Qt's "shortcomings" stem mainly from a difference of opinion on design. Qt takes a pretty "heavy" or "fat" object design, a lot like Java. The library is designed to add a lot of advanced features that C++ lacks by default, like introspection, object names and run-time type information. Signals and slots are pretty hefty, too. All this baggage might not be much of a performance bottleneck, especially in CPU time... in that regard it's a non-issue. However, there are a lot of extra dynamic memory allocations in there that aren't necessary in a more lightweight object/class design. I do prefer, in general, static linking and inline functions, which are both optimized for a more-memory-for-more-speed trade off. However, I think that data size is where the problem is, not code size. Of course, I need to look into this claim with some tools to profile memory usage before I really come to a full conclusion.