From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/83 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Anti-bloat side project Date: Mon, 27 Jun 2011 13:08:06 -0400 Message-ID: <20110627170806.GA24833@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309194903 30379 80.91.229.12 (27 Jun 2011 17:15:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Jun 2011 17:15:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-167-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 27 19:14:58 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QbFOk-0006DH-40 for gllmg-musl@lo.gmane.org; Mon, 27 Jun 2011 19:14:58 +0200 Original-Received: (qmail 7378 invoked by uid 550); 27 Jun 2011 17:14:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7360 invoked from network); 27 Jun 2011 17:14:56 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:83 Archived-At: One side effect of getting dynamic loading working, and being able to test Perl and Python a bit, is that I've seen a ridiculous level of inefficiency, especially in Python which is increasingly becoming a required dependency for many components of a "complete Linux system". As an example it takes Python nearly 600 syscalls just to run a hello world program, compared to about 40 for perl or bash and 20 for ash (and of course about 3 for musl-linked C using stdio). Much of this was spent searching nonsensical pathnames for config files and shared library modules. And let's not even get into the memory usage at this point... Anyway my idea for a side project to benefit the whole Linux community (not just musl users) is to document and analyze the causes of startup bloat/syscall bloat (which leads to bad performance, especially in "script"-type programs that run many times) and memory bloat in some core components that are used on most modern Linux-based systems: - Python - Perl - Glib - GTK - ncurses - etc. and then sending reports (and possible fix ideas) to the upstream maintainers. This is not something I plan to do myself (I'd rather spend time improving musl) but I want to propose it as a way for members of the community to contribute to positive anti-bloat work that benefits a large number of users, as opposed to the alternative of just boycotting software that "sucks" for bloat reasons. :-) Rich