Using scripting languages for KDE4 main modules
l.savernik at aon.at
Mon Oct 9 17:43:02 BST 2006
Am Sonntag, 8. Oktober 2006 20:21 schrieb Aaron J. Seigo:
> > > i don't think it's too much to ask for kjs or qsa. they are both
> > > lightweight and at least kjs is already in use on your desktop if you
> > > use konqi.
> > used, but only when web browsing certain pages. Sure, KDE user should
> > always have a Konqueror window open and they should use it as their
> > browser, so you have a point here. ;-)
> =) additionally, if no one has issues with it as part of the default web
> browser, why the issues with it elsewhere?
The fundamental problem with scripting languages, be it purely interpreted
like kjs or jitted like perl, which people tend to forget is this:
The real memory hog is the representation of the abstract syntax tree and all
accompanying management objects. For *every* statement, *every* variable,
*every* call, and *every* reference you need a dedicated object in memory
*which cannot be shared* (to the contrary of the native script interpreter's
machine code which, as an .so, *is* shared).
Those cannot be shared because they represent *different* scripts which are
going to be executed. Even jitted script-languages provide dynamic
introspection and evaluation features which still forces the engine to keep
elaborate AST-information around.
Therefore, really basic features like a *clock*-applet must not even remotely
be considered for contamination by scripts. (So, maybe there'll be a
clock-clock in C++ which fulfills nothing but the tasks of a clock in a
memory-efficient and performant way.)
More information about the kde-core-devel