On Wednesday 05 November 2008 15:05:13 Kuba Ober wrote: > > However, Trolltechs own demos segfault on my machine regularly > > and KDE is unreliable despite being written almost entirely in Qt's > > native language. So I would not be so hasty to blame PyQt for Qt's > > reliability problems. > > As a longtime KDE user, I'm very much disappointed by the most recent > major KDE release, in terms of how much slower it got on my > not-all-that-old-hardware (an AMD64 Compaq machine running in 32 bits). > A lot of it comes from the fact that my home directory is mounted via NFS, > but this used to work a lot better.
I now have a terabyte of ext3, 4Gb of RAM and eight 2.1GHz Opteron cores and KDE still runs like a dog, burning only 1 core at a time. This is a fresh install on a new machine as well, so distro baggage isn't the problem. > A typical KDE application literally hammers the filesystem upon every > single application startup, and it got progressively worse every major > KDE release. Qt is not an angel in that respect either -- that's about > the major gripe I have with Qt. I believe that fixing this is tantamount to Greenspunning managed C++ so I don't believe that will ever happen. Qt will be relegated to the embedded niche before dying completely. > As a longtime developer who uses Qt (recently only for open source stuff), > I do know that Qt's performance in general has continuously improved, and > they have made real low-level architectural improvements. New KDE releases > always hammered Qt pretty hard, it was a similar story when KDE 3 came > out, although the perceived slowdown wasn't as bad (and it was on worse > hardware). I think these are all knock-on effects. C++ is an awful programming language for high-level work because it is so inefficient (e.g. no GC). Qt is effectively C++-only so almost all non-trivial Qt applications are sluggish. If you build a GUI toolkit on a solid foundation like OCaml (when it gets its parallel GC) then GUI programming becomes much easier and much more efficient. That is unquestionably the way forward, as .NET has proven. Using Qt or C++ is just building on sand. > As for Qt demos segfaulting: I wonder if that may be due to OpenGL bugs. > Seriously. This is a high-performance OpenGL workstation that is used almost entirely for scientific visualization using OpenGL. None of our other software has any problems, just Qt. My guess is the Qt code isn't detecting error conditions at startup when it is obliged to, whereas glut and SDL are. Moreover, these are old bugs in Qt: I saw them years ago as well. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
