Glib or no glib - we need a decision
Enrico Weigelt
weigelt at metux.de
Fri Jan 9 16:12:44 UTC 2009
* Patrick Winnertz <winnie at debian.org> schrieb:
> contra:
> - glib is huge and we only use a very small amount of functions.
> Rewriting this functions would make mc smaller and faster. This is
> important at least for embedded devices.
Note that there's many many places where the glib functions aren't
needed at all.
a) wrappers for (often inline'd) libc functions (g_strcasecmp(), etc)
This actually costs resources, *at least* an extra far call up to
loosing the chance of inline'ing. It's IMHO stupid to use glib here
just to use it.
b) unncessary string duplications
c) often an static buffer on stack is cheaper
d) g_strconcat(): unnecessarily expensive and unrobust (just forget
the last NULL parameter and go straight to hell) - I've replaced
it by several faster inlines in my branch
e) many things can be expressed more clear, cheaper and more robust
through a few little macros.
f) some glib functions are simply broken and must be circumvented
at all (eg. shell-escaping ...)
So my vote is to at least get rid of the unncessary glib calls,
then let's see what remains and wether it's worth to keep it just
for that few things
BTW: glib is far from being robust over several versions. Just look
at the 1.*/2.* issue: they actually call the 2.* successor versions
of 1.*, but they're totally different things that just happen to
share the name and some ideas behind. And even within the 2.* line
there've been major interface breaks. Keep that in mind!
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
More information about the mc-devel
mailing list