From: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>, "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: code bloat [was Re: Semaphore assembly-code bug]
Date: Mon, 1 Nov 2004 15:40:25 +0200
User-Agent: KMail/1.5.4
Cc: Jeff Garzik <jgarzik@pobox.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <417550FB.8020404@drdos.com.suse.lists.linux.kernel> <20041031201500.GA4498@thunk.org> <1099308472.18809.60.camel@localhost.localdomain>
In-Reply-To: <1099308472.18809.60.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200411011540.25175.vda@port.imtp.ilyichevsk.odessa.ua>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1012
Lines: 31

On Monday 01 November 2004 13:27, Alan Cox wrote:
> 2. Most of the pages of libxml2.so don't get paged in by a typical
> application

This assumes that 'needed' functions are close together.
This can be easily not the case, so you end up using only
a fraction of fetched page's content.

Also this argument tend to defend library growth.
"It's mostly unused, don't worry". What if that
is not true? How to compare RAM footprint
of new versus old lib in this case?
Just believe that it didn't get worse?

This can't be checked easily:
even -static compile can fail to help.
glibc produce nearly 400kb executable for

int main() { return 0; }

because init code uses printf on error paths and
that pulls i18n in. How many kilobytes is really
runs - who knows...
--
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/