These tools are likely to be running in the background on many systems:
getty init klogd syslogd udhcpc
(also ash/sh but a static dietlibc version of dash is available for that)
The standard Puppy busybox (compiled with shared gnu libc and almost all applets) uses almost 2mb per instance, but by compiling just these critical apps statically against a small libc reduces this to less than 200kb each (dietlibc isn't fully compatible so I used uclibc)
Any other busybox tools that are constantly running in other popular puplets let me know... perhaps someone wants to patch freememapplet to use busybox's inotifyd instead of inotifywait?...I could add hush so it could be used for scripts, but then you would still have to mod your scripts, so may as well use dash.
busybox daemons - 90% reduction in resource usage
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
busybox daemons - 90% reduction in resource usage
- Attachments
-
- busybox-daemons-1.17.2.pet
- (52.57 KiB) Downloaded 735 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Great!
Small test of mem usage in 3 different situations:
(download approx. midle of page) it seems you can reduce from using 1392K to approx. 248K as well. Static udevd is 82K whereas the dyn version is 63K so increase in size seems reasonably ok...
Someone with better compiling skills than I have might even reduce size of binary even more...
Concerning freememapplet_tray: Maybe a total redesign is worth thinking of - the total size of all the dependencies of freememapplet_tray is 8,8Mb!
Small test of mem usage in 3 different situations:
- getty init klogd syslogd udhcpc: all BB = 5 x 1528K = 7640K
- getty+init+udhcpc from BB and klogd+syslogd build with static ulibc: 3 x 1528K + 164K + 192K = 4940K
- getty init klogd syslogd udhcpc from above: 192K + 192K + 184K + 188K + 188K = 944K
(download approx. midle of page) it seems you can reduce from using 1392K to approx. 248K as well. Static udevd is 82K whereas the dyn version is 63K so increase in size seems reasonably ok...
Someone with better compiling skills than I have might even reduce size of binary even more...
Concerning freememapplet_tray: Maybe a total redesign is worth thinking of - the total size of all the dependencies of freememapplet_tray is 8,8Mb!
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
thats about what I got with Rob Landley's cross compiler tools from http://impactlinux.com/aboriginal/downloads/binaries/ that I have been using instead of my devx.
(also copy include in /usr/cc and /usr/c++ to just /usr/include and link /usr/${PLATFORM}/bin/cc1 to /usr/bin (ro modify $PATH) or you'll have to add a bunch of unnecessary compiler flags)
This is what I use:
CC="gcc -muclibc" \
CFLAGS=" -Os -ffunction-sections -fdata-sections -finline-functions-called-once -march=${CROSS} -mtune=${CROSS} " \
LDFLAGS=" -Wl,-Os,--relax,--gc-sections,--sort-common,-s " \
CXXFLAGS=${CFLAGS} -fno-rtti " \
./configure --prefix=/usr ... --build=$PLATFORM --enable-static --disable-shared ....
Re: freemem
I wrote a script a while back that will write a horizontal or vertical percentage based 2-color xpm icon (it considerably speeds up Barry's partimage script and others where several images need to be created). It could probably even be modified to create a scrolling graph... the demo apps in xfree86 may be a good start for something to refresh an xpm image(s) that jwm could swallow. (same for cpu and others)... ideally one tray applet would be able to display all the icons and have a single script to either generate the icons or updates a symlink to the appropriate icon (as in blinky, volume, mail...).
btw I would have ported udevd to busybox already, but I would rather try and see if in fact mdev -d would be a suitable replacement
also it has been my experience that most CLI apps compiled statically against uclibc based libs and upx'd are roughly the same size or smaller than their shared gnu counterpart and load faster because decompression is much quicker than finding all libs and then the relocations etc...
(also copy include in /usr/cc and /usr/c++ to just /usr/include and link /usr/${PLATFORM}/bin/cc1 to /usr/bin (ro modify $PATH) or you'll have to add a bunch of unnecessary compiler flags)
This is what I use:
CC="gcc -muclibc" \
CFLAGS=" -Os -ffunction-sections -fdata-sections -finline-functions-called-once -march=${CROSS} -mtune=${CROSS} " \
LDFLAGS=" -Wl,-Os,--relax,--gc-sections,--sort-common,-s " \
CXXFLAGS=${CFLAGS} -fno-rtti " \
./configure --prefix=/usr ... --build=$PLATFORM --enable-static --disable-shared ....
Re: freemem
I wrote a script a while back that will write a horizontal or vertical percentage based 2-color xpm icon (it considerably speeds up Barry's partimage script and others where several images need to be created). It could probably even be modified to create a scrolling graph... the demo apps in xfree86 may be a good start for something to refresh an xpm image(s) that jwm could swallow. (same for cpu and others)... ideally one tray applet would be able to display all the icons and have a single script to either generate the icons or updates a symlink to the appropriate icon (as in blinky, volume, mail...).
btw I would have ported udevd to busybox already, but I would rather try and see if in fact mdev -d would be a suitable replacement
also it has been my experience that most CLI apps compiled statically against uclibc based libs and upx'd are roughly the same size or smaller than their shared gnu counterpart and load faster because decompression is much quicker than finding all libs and then the relocations etc...
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
I haven't been able to figure out how to use mdev -d - at least not to do the automatic module loading - and static udev is working and small.
Concerning cli static builds the following example confirms your findings:
#dialog case
static (libc) upxed: 277K
dynamic: 103K + libncourses 220K (dialog upxed would be 51K)
Haven't been able to compile dialog against uclibc but even using normal libc the total size of the static upxed build is equivalent to the size using the dynamic build plus its libs.
Did some small test that puzzles me - viewing tops report using all BB version and using your "getty init klogd syslogd udhcpc "-static version:
BB top after boot:
mem 10360K used 836K free 324K bufff 3616 cached
"getty init klogd syslogd udhcpc "-static used after boot:
mem 10328K used 868K free 232 buff 3752 cached
It does not reflect the reported mem use for the single PIDs - why?
Is there any other way do confirm that the static build binaries uses less mem?
Concerning cli static builds the following example confirms your findings:
#dialog case
static (libc) upxed: 277K
dynamic: 103K + libncourses 220K (dialog upxed would be 51K)
Haven't been able to compile dialog against uclibc but even using normal libc the total size of the static upxed build is equivalent to the size using the dynamic build plus its libs.
Did some small test that puzzles me - viewing tops report using all BB version and using your "getty init klogd syslogd udhcpc "-static version:
BB top after boot:
mem 10360K used 836K free 324K bufff 3616 cached
"getty init klogd syslogd udhcpc "-static used after boot:
mem 10328K used 868K free 232 buff 3752 cached
It does not reflect the reported mem use for the single PIDs - why?
Is there any other way do confirm that the static build binaries uses less mem?
looks good
Dear technosaurus,
I have the feeling that you are on to a good thing here. Keep at it, please.
With kind regards,
vovchik
I have the feeling that you are on to a good thing here. Keep at it, please.
With kind regards,
vovchik