Messages in this thread | | | Date | Sun, 31 Oct 2004 07:49:27 +0100 (MET) | From | Jan Engelhardt <> | Subject | Re: code bloat [was Re: Semaphore assembly-code bug] |
| |
>> 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/
| |