[maemo-developers] Let's break this silence
From: koos vriezen koos.vriezen at gmail.comDate: Sat Aug 21 10:56:47 EEST 2010
- Previous message: Python bindings for Qt Mobility APIs now available
- Next message: Let's break this silence
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi, Cross posting because I'm curious about meego efforts to create a Qt application booster. 2010/8/21 Mohammad Ebrahim Mohammadi Panah <ebrahim at mohammadi.ir>: > Now what? > I think there is room to make KDE faster and less memory hungry, > although I haven't dug deep into the issue. I thought I should discuss > the issue with you, the more experienced KDE developers/optimizers, to > see what's your idea. Is there any plan/roadmap/strategy for > optimizing KDE? Any guides or guidelines? Have you documented your KDE > optimization experience anywhere? What's your ideas about how we can > optimize KDE? After seeing the googletechtalk about the Android dalvik virtual machine, the idea of tuning kdeinit to be more fork/loadlibrary+call kdemain friendly is interesting. To summarize, Android managed to limit memory by using a vm that loads lots of often used classes and then forks, changes uid and then starts the required dex program. A bit like kdeinit, but kdeinit only loads libraries to resolve the exported symbols making the startup faster. Dalvik also loads and initialized parts of the program. And they tuned e.g. the vm garbage collector to not write in the memory block where the object are, so the copy-on-write mechanism of the kernel doesn't kick in. E.g. fontconfig FcInit, split QApplication construction are IMO things to look at. Thus may need help from the upstream projects too. Just a thought of course. Koos
- Previous message: Python bindings for Qt Mobility APIs now available
- Next message: Let's break this silence
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]