Using scripting languages for KDE4 main modules
cberger at cberger.net
Sun Oct 1 18:25:05 BST 2006
> My list is purportedly encompassing to prevent this:
> - A writes support for new important formula for kspread in ruby
> - B writes new important dialog for kspread in python
> - C writes new important other functionality for kspread in fooblargh
> - ...
> (where "new important" means functionality already contained in excel whose
> support is considered crucial to be perceived as a "full blown" app)
> Then we already have three script interpreters+runtimes+bindings hogging
> memory and drowning performance.
Well I did some benchmark with krita 1.6svn. Using ps, if anyone knows a
better way to profile memory consumption, I am ready to give it a try.
The test is the following:
creates a 1x1 pixel image (to limit the memory increase of memory due to
operations on a big image)
2.2 krita at start
2.3 krita after running the ruby invert filter
2.4 krita after running the python invert filter
2.4 krita after running the python invert filter a second time
2.4 krita after running the C++ invert filter
Then after removing the kross plugins (and therefor no link anymore to
2.2 krita after running the C++ invert filter
0.1% of memory correspond to 2Mo of memory on my system (I wish I had a better
way to measure it)
Which means ruby and python's library with debug symbols increase the memory
taken by an application of 2Mo each... I don't consider it memory hogging and
A final test to see the cost of the binding:
2.7 krita after running a script that loads the korundum binding
It would be interesting to know why that increase so much the memory
consumption, but for kross we were thinking of adding some very basic binding
to ui to avoid loading the full binding for the language.
> Another hypothetical example (not that far fetched) pretending krita needs
> python and ruby binding to work:
> - kword user doesn't have python and ruby installed.
> - wants to paste image into kword
> - krita flake refuses to load
> => no images in kword documents.
that depends how you construct your application, krita is splitted in two : on
one side the core libraries, and then plugins which brings functionality to
krita. Core libraries are C++ and will remain C++ only. Kross is one of the
plugins, and each of the interpreter (ruby, python, kjs) is a plug-in that is
only loaded if the interpreter is available. That means, if python is not
available, in the worse situation, some functions are just not available,
filters or automation mostly.
--- Cyrille Berger ---
More information about the kde-core-devel