![]() | |||||||||||||
Messages in this thread |
>> Hmm probably some bloat-detection tools would be helpful, >> like "show me source_lines/object_size ratios of fonctions in >> this ELF object file". Those with low ratio are suspects of >> excessive inlining etc. Hm, I've got a (very simple) line determining utility, http://linux01.org:2222/f/UHXT/bin/sourcefuncsize maybe someone can pipe it together with ls -l or whatever. >The problem with apps of this sort is the multiple layers of abstraction. >>Xlib, GLib, GTK, GNOME, Pango, XML, etc. At least they know one thing: that thou should not stuff everything into one .so but multiple ones (if it's a lot). That /may/ reduce the size-in-memory, because not all .so's need to be loaded. OTOH, most apps load /all/ anyway. Heh, there we go. >Bloat is cause by feature creep at every layer, not just the app. I sense Java and C# being the best example. Z Smith wrote: >Or join me in my effort to limit bloat. Why use an X server >that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes >of code with very minimal kmallocing? FBUI does not have 3d acceleration? Ken Moffat wrote: >>The point is that -Os is *much* less tested>>than -O2 at the moment. >Because people suck, and don't use it and hence test it. I doubt even the -O2-only-people use gprof/gcov frequently. :( Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 14:07 [from the cache] ©2003-2008 | |||||||||||||