* Patrick Winnertz <win...@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/ --------------------------------------------------------------------- _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel