lkml.org 
[lkml]   [2004]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: code bloat [was Re: Semaphore assembly-code bug]
Date
On Sunday 31 October 2004 01:27, Tim Hockin wrote:
> On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote:
> > I am not a code genius, but want to help.
> >
> > 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.
>
> The problem with apps of this sort is the multiple layers of abstraction.
>
> Xlib, GLib, GTK, GNOME, Pango, XML, etc.

I think it makes sense to start from lower layers first:

Kernel team is reasonably aware of the bloat danger.

glibc is worse, but thanks to heroic actions of Eric Andersen
we have mostly feature complete uclibc, 4 times (!)
smaller than glibc.

Xlib, GLib.... - didn't look into them apart from cases
when they do not build or in bug hunting sessions.
Quick data point: glib-1.2.10 is 1/2 of uclibc in size.
glib-2.2.2 is 2 times uclibc. x4 growth :(

> No one wants to duplicate effort (rightly so). Each of these libs tries
> to do EVERY POSSIBLE thing. They all end up bloated. Then you have to
> link them all in. You end up bloated. Then it is very easy to rely on
> those libs for EVERYTHING, rather thank actually thinking.
>
> So you end up with the mindset of, for example, "if it's text it's XML".
> You have to parse everything as XML, when simple parsers would be tons
> faster and simpler and smaller.
>
> Bloat is cause by feature creep at every layer, not just the app.

I actually tried to convince maintainers of one package
that their code is needlessly complex. I did send patches
to remedy that a bit while fixing real bugs. Rejected.
Bugs were planned to be fixed by adding more code.
I've lost all hope on that case.

I guess this is a reason why bloat problem tend to be solved
by rewrite from scratch. I could name quite a few cases:

glibc -> dietlibc,uclibc
coreutils -> busybox
named -> djbdns
inetd -> daemontools+ucspi-tcp
sendmail -> qmail
syslogd -> socklog (http://smarden.org/socklog/)

It's sort of frightening that someone will need to
rewrite Xlib or, say, OpenOffice :(
--
vda

-
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    [W:0.151 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site