* Anti-bloat side project
@ 2011-06-27 17:08 Rich Felker
2011-06-27 21:16 ` Szabolcs Nagy
0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2011-06-27 17:08 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-27 17:08 Anti-bloat side project Rich Felker
@ 2011-06-27 21:16 ` Szabolcs Nagy
2011-06-27 21:19 ` Rich Felker
0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2011-06-27 21:16 UTC (permalink / raw)
To: musl
* Rich Felker <dalias@aerifal.cx> [2011-06-27 13:08:06 -0400]:
> 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
i get different numbers on my (ubuntu) system
nsz@tpx:~$ strace python -c '' 2>&1 |wc -l
670
nsz@tpx:~$ strace perl -e '' 2>&1 |wc -l
176
nsz@tpx:~$ strace sh -c '' 2>&1 |wc -l
42
nsz@tpx:~$ strace bash -c '' 2>&1 |wc -l
186
nsz@tpx:~$ strace awk '' 2>&1 |wc -l
95
nsz@tpx:~$ strace mawk '' 2>&1 |wc -l
39
nsz@tpx:~$ strace lua -e '' 2>&1 |wc -l
67
nsz@tpx:~$ strace bc </dev/null 2>&1 |wc -l
60
nsz@tpx:~$ strace sed '' </dev/null 2>&1 |wc -l
110
nsz@tpx:~$ strace cat </dev/null 2>&1 |wc -l
111
nsz@tpx:~$ strace dd </dev/null 2>&1 |wc -l
162
nsz@tpx:~$ strace grep . </dev/null 2>&1 |wc -l
127
nsz@tpx:~$ strace /bin/true 2>&1 |wc -l
107
without locale crap
nsz@tpx:~$ export LC_ALL=C
nsz@tpx:~$ strace python -c '' 2>&1 |wc -l
652
nsz@tpx:~$ strace perl -e '' 2>&1 |wc -l
99
nsz@tpx:~$ strace sh -c '' 2>&1 |wc -l
42
nsz@tpx:~$ strace bash -c '' 2>&1 |wc -l
101
nsz@tpx:~$ strace awk '' 2>&1 |wc -l
55
nsz@tpx:~$ strace mawk '' 2>&1 |wc -l
39
nsz@tpx:~$ strace lua -e '' 2>&1 |wc -l
67
nsz@tpx:~$ strace bc </dev/null 2>&1 |wc -l
60
nsz@tpx:~$ strace sed '' </dev/null 2>&1 |wc -l
35
nsz@tpx:~$ strace cat </dev/null 2>&1 |wc -l
36
nsz@tpx:~$ strace dd </dev/null 2>&1 |wc -l
74
nsz@tpx:~$ strace grep . </dev/null 2>&1 |wc -l
40
nsz@tpx:~$ strace /bin/true 2>&1 |wc -l
32
> 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. :-)
nice
imho these issues are well known, ppl just don't care enough
i remember when the first google summer of codes was announced
one of the first python project idea was to do something
about the number of syscalls at startup
http://wiki.python.org/moin/CodingProjectIdeas/PythonCore
it did not improve much since then, even in python3 ppl are
complaining about the syscalls but devs say it does not matter
http://mail.python.org/pipermail/python-dev/2011-January/107771.html
http://mail.python.org/pipermail/python-dev/2011-January/107789.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-27 21:16 ` Szabolcs Nagy
@ 2011-06-27 21:19 ` Rich Felker
2011-06-27 21:38 ` Szabolcs Nagy
0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2011-06-27 21:19 UTC (permalink / raw)
To: musl
On Mon, Jun 27, 2011 at 11:16:25PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2011-06-27 13:08:06 -0400]:
> > 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
>
> i get different numbers on my (ubuntu) system
Yes, I was measuring with musl... Thanks for the figures.
> > 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. :-)
>
> nice
> imho these issues are well known, ppl just don't care enough
>
> i remember when the first google summer of codes was announced
> one of the first python project idea was to do something
> about the number of syscalls at startup
> http://wiki.python.org/moin/CodingProjectIdeas/PythonCore
>
> it did not improve much since then, even in python3 ppl are
> complaining about the syscalls but devs say it does not matter
> http://mail.python.org/pipermail/python-dev/2011-January/107771.html
> http://mail.python.org/pipermail/python-dev/2011-January/107789.html
Bleh. Has there been any serious work to document the causes and how
the code could be changed to fix the syscall bloat though? Or just
preliminat strace and wc -l?
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-27 21:38 ` Szabolcs Nagy
@ 2011-06-27 21:37 ` Rich Felker
2011-06-27 21:43 ` Rich Felker
0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2011-06-27 21:37 UTC (permalink / raw)
To: musl
On Mon, Jun 27, 2011 at 11:38:05PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2011-06-27 17:19:09 -0400]:
> > Bleh. Has there been any serious work to document the causes and how
> > the code could be changed to fix the syscall bloat though? Or just
> > preliminat strace and wc -l?
>
> most of the syscalls are due to python module imports check
> 100 different locations before finding the good one
>
> imho they measured it and concluded that with modern
> filesystem caching this does not matter much..
Well they're wrong. Even if the syscall did nothing but enter and
leave kernelspace, it would still be very expensive. Using a module
cache/registry of some sort could solve the problem, or they could
first tackle all the non-open() syscalls which still make up a heavy
share of the cost..
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-27 21:19 ` Rich Felker
@ 2011-06-27 21:38 ` Szabolcs Nagy
2011-06-27 21:37 ` Rich Felker
0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2011-06-27 21:38 UTC (permalink / raw)
To: musl
* Rich Felker <dalias@aerifal.cx> [2011-06-27 17:19:09 -0400]:
> Bleh. Has there been any serious work to document the causes and how
> the code could be changed to fix the syscall bloat though? Or just
> preliminat strace and wc -l?
most of the syscalls are due to python module imports check
100 different locations before finding the good one
imho they measured it and concluded that with modern
filesystem caching this does not matter much..
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-27 21:37 ` Rich Felker
@ 2011-06-27 21:43 ` Rich Felker
2011-06-29 14:19 ` Szabolcs Nagy
0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2011-06-27 21:43 UTC (permalink / raw)
To: musl
On Mon, Jun 27, 2011 at 05:37:39PM -0400, Rich Felker wrote:
> On Mon, Jun 27, 2011 at 11:38:05PM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@aerifal.cx> [2011-06-27 17:19:09 -0400]:
> > > Bleh. Has there been any serious work to document the causes and how
> > > the code could be changed to fix the syscall bloat though? Or just
> > > preliminat strace and wc -l?
> >
> > most of the syscalls are due to python module imports check
> > 100 different locations before finding the good one
> >
> > imho they measured it and concluded that with modern
> > filesystem caching this does not matter much..
>
> Well they're wrong. Even if the syscall did nothing but enter and
> leave kernelspace, it would still be very expensive. Using a module
> cache/registry of some sort could solve the problem, or they could
> first tackle all the non-open() syscalls which still make up a heavy
> share of the cost..
Of course a better question is... why does "hello world" need to load
any modules anyway? Perhaps a best first step to fixing the problem
would be to demodularize and static link any module that will always
be loaded...
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-27 21:43 ` Rich Felker
@ 2011-06-29 14:19 ` Szabolcs Nagy
2011-06-29 19:27 ` Rich Felker
0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2011-06-29 14:19 UTC (permalink / raw)
To: musl
* Rich Felker <dalias@aerifal.cx> [2011-06-27 17:43:00 -0400]:
> Of course a better question is... why does "hello world" need to load
> any modules anyway? Perhaps a best first step to fixing the problem
> would be to demodularize and static link any module that will always
> be loaded...
btw applications are worse even if they are written in c
gtk hello:
$ strace zenity --info --text=hello 2>&1 |wc -l
6491
x terminal emulators:
$ strace xterm -e /bin/true 2>&1 |wc -l
1214
$ strace urxvt -e /bin/true 2>&1 |wc -l
850
firefox with a newly created empty profile
(no extensions, and blank page):
$ strace -f firefox -P empty -url about:blank 2>&1 |wc -l
17980
(ff has many periodic timers and does many things in the
background so the number depends on how fast i kill the
apearing window but it's always >16000)
$ strace -c -Scalls zenity --info --text=hello
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
13.70 0.000181 0 1510 417 stat64
9.84 0.000130 0 1277 573 open
59.95 0.000792 1 988 getdents64
2.42 0.000032 0 706 close
1.97 0.000026 0 672 fstat64
2.42 0.000032 0 560 92 read
2.95 0.000039 0 174 mmap2
6.74 0.000089 1 157 select
0.00 0.000000 0 101 68 access
0.00 0.000000 0 80 writev
0.00 0.000000 0 58 gettimeofday
0.00 0.000000 0 55 mprotect
0.00 0.000000 0 36 poll
0.00 0.000000 0 19 munmap
0.00 0.000000 0 17 brk
0.00 0.000000 0 8 uname
0.00 0.000000 0 6 fcntl64
0.00 0.000000 0 4 _llseek
0.00 0.000000 0 4 futex
...
100.00 0.001321 6463 1153 total
$ strace -c -Scalls -f firefox -P empty -url about:blank
...
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
0.01 0.000104 0 2244 1010 close
0.03 0.000355 0 2099 988 open
0.01 0.000159 0 1924 520 stat64
0.01 0.000093 0 1826 gettimeofday
0.19 0.002521 2 1595 284 read
0.00 0.000000 0 1112 fstat64
0.03 0.000333 0 994 getdents64
0.01 0.000160 0 662 mmap2
64.14 0.849392 1361 624 26 futex
0.01 0.000075 0 623 1 madvise
0.00 0.000036 0 481 select
0.00 0.000000 0 462 301 access
0.01 0.000069 0 267 writev
0.00 0.000000 0 228 fcntl64
0.00 0.000000 0 213 mprotect
0.00 0.000036 0 167 _llseek
0.00 0.000000 0 160 clock_gettime
0.00 0.000000 0 140 munmap
16.92 0.224014 1882 119 poll
0.00 0.000000 0 92 3 lstat64
0.00 0.000000 0 53 write
0.00 0.000000 0 52 rt_sigaction
0.00 0.000000 0 51 lseek
0.00 0.000000 0 46 brk
0.00 0.000000 0 41 getdents
0.00 0.000000 0 25 uname
0.09 0.001185 59 20 4 execve
0.24 0.003125 156 20 clone
0.00 0.000000 0 19 pipe
0.00 0.000000 0 18 socket
0.00 0.000000 0 16 set_thread_area
0.48 0.006364 424 15 2 wait4
0.00 0.000000 0 15 7 connect
0.00 0.000000 0 14 dup2
0.00 0.000000 0 12 getuid32
0.00 0.000000 0 11 geteuid32
0.00 0.000000 0 9 time
0.00 0.000000 0 8 1 readlink
0.00 0.000000 0 8 sched_get_priority_max
0.00 0.000000 0 8 getgroups32
0.00 0.000000 0 7 sched_get_priority_min
0.00 0.000000 0 7 set_robust_list
0.00 0.000000 0 6 sched_setscheduler
0.00 0.000000 0 5 getgid32
0.00 0.000000 0 5 getegid32
0.00 0.000000 0 4 getpid
0.00 0.000000 0 4 4 mkdir
0.00 0.000000 0 4 getppid
0.00 0.000000 0 4 getsockname
...
100.00 1.324219 16588 3153 total
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-29 14:19 ` Szabolcs Nagy
@ 2011-06-29 19:27 ` Rich Felker
2011-06-29 20:03 ` Szabolcs Nagy
0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2011-06-29 19:27 UTC (permalink / raw)
To: musl
On Wed, Jun 29, 2011 at 04:19:45PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2011-06-27 17:43:00 -0400]:
> > Of course a better question is... why does "hello world" need to load
> > any modules anyway? Perhaps a best first step to fixing the problem
> > would be to demodularize and static link any module that will always
> > be loaded...
>
> btw applications are worse even if they are written in c
Well we're now talking about applications which actually DO
something...
> gtk hello:
> $ strace zenity --info --text=hello 2>&1 |wc -l
> 6491
What about the gtk hello world from the gtk tutorial?
> x terminal emulators:
> $ strace xterm -e /bin/true 2>&1 |wc -l
> 1214
> $ strace urxvt -e /bin/true 2>&1 |wc -l
> 850
These numbers are not that bad... only about twice as much as Python
and doing A LOT more. By the way, uuterm is 525, so the vast majority
of that is xlib... (Of course then uuterm starts the evil blinking
cursor if you leave it sitting.. ;)
> $ strace -c -Scalls zenity --info --text=hello
> % time seconds usecs/call calls errors syscall
> ------ ----------- ----------- --------- --------- ----------------
> 13.70 0.000181 0 1510 417 stat64
> 9.84 0.000130 0 1277 573 open
> 59.95 0.000792 1 988 getdents64
Looks like it's performing a lot of scandir or glob...
> $ strace -c -Scalls -f firefox -P empty -url about:blank
> ....
> 64.14 0.849392 1361 624 26 futex
624 cases of lock contention during startup is pretty bad...
> 0.24 0.003125 156 20 clone
Of course 20 threads could contribute to that...
> 0.48 0.006364 424 15 2 wait4
And lots of child processes..?!
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-29 19:27 ` Rich Felker
@ 2011-06-29 20:03 ` Szabolcs Nagy
2011-08-16 13:03 ` Moritz Wilhelmy
0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2011-06-29 20:03 UTC (permalink / raw)
To: musl
* Rich Felker <dalias@aerifal.cx> [2011-06-29 15:27:36 -0400]:
> On Wed, Jun 29, 2011 at 04:19:45PM +0200, Szabolcs Nagy wrote:
> > gtk hello:
> > $ strace zenity --info --text=hello 2>&1 |wc -l
> > 6491
>
> What about the gtk hello world from the gtk tutorial?
>
ok that's better, "only" 1400 syscalls
many of it is about dynamic linking, reading large config files
locale things and of course communicating with x
$ strace -c -Scalls ./t
Hello World
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
17.65 0.000099 0 321 78 read
0.00 0.000000 0 219 82 open
5.53 0.000031 0 160 mmap2
0.00 0.000000 0 139 close
0.00 0.000000 0 124 1 select
0.00 0.000000 0 106 fstat64
7.13 0.000040 0 93 60 access
6.60 0.000037 1 64 writev
0.00 0.000000 0 58 1 stat64
63.10 0.000354 7 49 mprotect
0.00 0.000000 0 27 poll
0.00 0.000000 0 16 gettimeofday
0.00 0.000000 0 16 munmap
0.00 0.000000 0 10 brk
0.00 0.000000 0 7 uname
0.00 0.000000 0 6 fcntl64
0.00 0.000000 0 3 1 lstat64
0.00 0.000000 0 3 futex
0.00 0.000000 0 3 socket
0.00 0.000000 0 3 2 connect
...
100.00 0.000561 1448 225 total
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-06-29 20:03 ` Szabolcs Nagy
@ 2011-08-16 13:03 ` Moritz Wilhelmy
2011-08-16 13:06 ` Rich Felker
0 siblings, 1 reply; 13+ messages in thread
From: Moritz Wilhelmy @ 2011-08-16 13:03 UTC (permalink / raw)
To: musl
Hello,
While debugging mlmmj, my mailing list manager of choice, I noted that
it calls read(2) really, really often, in order to read a single byte
out of a fd, and then read the next byte, like this:
open("/var/spool/mlmmj/foo/control/listaddress", O_RDONLY) = 4
read(4, "f", 1) = 1
read(4, "o", 1) = 1
read(4, "o", 1) = 1
read(4, "@", 1) = 1
read(4, "l", 1) = 1
read(4, "i", 1) = 1
read(4, "s", 1) = 1
read(4, "t", 1) = 1
read(4, "s", 1) = 1
read(4, ".", 1) = 1
read(4, "e", 1) = 1
read(4, "x", 1) = 1
read(4, "a", 1) = 1
read(4, "m", 1) = 1
read(4, "p", 1) = 1
read(4, "l", 1) = 1
read(4, "e", 1) = 1
read(4, ".", 1) = 1
read(4, "c", 1) = 1
read(4, "o", 1) = 1
read(4, "m", 1) = 1
read(4, "\n", 1) = 1
close(4) = 0
It does this for every file it touches as well as network connections it
reads from.
I don't know yet, how and why exactly it does it this way, but it seems
rather insane to me, so I think it might need some patches in order to
clean it up.
It turned out that attempting to subscribe someone to a mailing list
used 794 read(x, y, 1) style syscalls. I don't think I want to know how
often it calls read() in order to post a message to all members of the
list.
Maybe this could be solved by using getline(3) instead, which is in
POSIX.1-2008 and implemented on current versions of at least glibc,
FreeBSD, NetBSD and of course musl.
I will contact the mlmmj developers and try to resolve the issue.
Solar, maybe you should still wait a bit before switching openwall over
to mlmmj ;)
Best,
Moritz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-08-16 13:03 ` Moritz Wilhelmy
@ 2011-08-16 13:06 ` Rich Felker
2011-08-16 13:16 ` Moritz Wilhelmy
0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2011-08-16 13:06 UTC (permalink / raw)
To: musl
On Tue, Aug 16, 2011 at 03:03:50PM +0200, Moritz Wilhelmy wrote:
> Hello,
>
> While debugging mlmmj, my mailing list manager of choice, I noted that
> it calls read(2) really, really often, in order to read a single byte
> out of a fd, and then read the next byte, like this:
>
> open("/var/spool/mlmmj/foo/control/listaddress", O_RDONLY) = 4
> read(4, "f", 1) = 1
> read(4, "o", 1) = 1
> read(4, "o", 1) = 1
> read(4, "@", 1) = 1
Is it possibly implemented as a shell script? The way the shell "read"
command works, it's required to perform byte-at-a-time reads like
this. Otherwise, I'm guessing someone just foolishly turned off
buffering on the FILE...
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-08-16 13:06 ` Rich Felker
@ 2011-08-16 13:16 ` Moritz Wilhelmy
2011-08-16 13:52 ` Rich Felker
0 siblings, 1 reply; 13+ messages in thread
From: Moritz Wilhelmy @ 2011-08-16 13:16 UTC (permalink / raw)
To: musl
On Tue, Aug 16, 2011 at 09:06:43 -0400, Rich Felker wrote:
> Is it possibly implemented as a shell script? The way the shell "read"
> command works, it's required to perform byte-at-a-time reads like
> this. Otherwise, I'm guessing someone just foolishly turned off
> buffering on the FILE...
In fact, it really is a C program, and sadly, it seems they really
implement it that way (by greping over the code for about 30 seconds);
See src/mygetline.c on hg tip[1]:
41 while(1) {
42 res = read(fd, &ch, 1);
Maybe coders need to be educated about how not to write code in order to
avoid (syscall-)bloat?
[1]: http://mlmmj.org/hg/mlmmj/file/tip/src/mygetline.c
Moritz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Anti-bloat side project
2011-08-16 13:16 ` Moritz Wilhelmy
@ 2011-08-16 13:52 ` Rich Felker
0 siblings, 0 replies; 13+ messages in thread
From: Rich Felker @ 2011-08-16 13:52 UTC (permalink / raw)
To: musl
On Tue, Aug 16, 2011 at 03:16:10PM +0200, Moritz Wilhelmy wrote:
> On Tue, Aug 16, 2011 at 09:06:43 -0400, Rich Felker wrote:
> > Is it possibly implemented as a shell script? The way the shell "read"
> > command works, it's required to perform byte-at-a-time reads like
> > this. Otherwise, I'm guessing someone just foolishly turned off
> > buffering on the FILE...
>
> In fact, it really is a C program, and sadly, it seems they really
> implement it that way (by greping over the code for about 30 seconds);
>
> See src/mygetline.c on hg tip[1]:
> 41 while(1) {
> 42 res = read(fd, &ch, 1);
>
> Maybe coders need to be educated about how not to write code in order to
> avoid (syscall-)bloat?
>
> [1]: http://mlmmj.org/hg/mlmmj/file/tip/src/mygetline.c
As they're using a file descriptor rather than a FILE or their own
higher-level buffering structure, the design forces them to either
require that the file descriptor be seekable (so they can seek back
after reading too much) or read one byte at a time.
I'm not sure why someone would use file descriptors rather than stdio
or something similar for processing text.. Looks lke just a bad
design. There's no immediate fix, however, as the issue is a result of
the design.
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-08-16 13:52 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-27 17:08 Anti-bloat side project Rich Felker
2011-06-27 21:16 ` Szabolcs Nagy
2011-06-27 21:19 ` Rich Felker
2011-06-27 21:38 ` Szabolcs Nagy
2011-06-27 21:37 ` Rich Felker
2011-06-27 21:43 ` Rich Felker
2011-06-29 14:19 ` Szabolcs Nagy
2011-06-29 19:27 ` Rich Felker
2011-06-29 20:03 ` Szabolcs Nagy
2011-08-16 13:03 ` Moritz Wilhelmy
2011-08-16 13:06 ` Rich Felker
2011-08-16 13:16 ` Moritz Wilhelmy
2011-08-16 13:52 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).