Re: Glib or no glib - we need a decision



* Patrick Winnertz <winnie 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/
---------------------------------------------------------------------


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]