RAM is quite cheap now. It is quite difficult to find anybody running a system with less than 64M of RAM. CPUs are fast. It is 21st century, after all. Is Pike's target market 486dx33 with 8MB RAM? I doubt that.
I would argue that why can't Pike's target market be 486dx33's? I personally have tried to install pike on a 32MB CRAMFS partition on a embedded machine, and it just can't be done. This is a real pity because with things like it's easy to use HTTP stack and good networking it is an excellent choice for embedded applications.
I think real effort should go into making pike smaller, as well as making it bigger.
[jnt@rusty]~$ du -sh /sw/lib/pike/ 18M /sw/lib/pike
See what I mean?
--- James Tyson Director, Giant Robot Ltd http://www.giantrobot.co.nz/
I think that a more modular design would solve that; I imagine a "base" pike with add-on modules (including Protocols, Image and GTK) could work to solve the installation need, as well as separating everything that doesn't need to follow the main Pike version and release cycle.
/ Mirar
Previous text:
2003-10-08 11:20: Subject: time() and optimization again
RAM is quite cheap now. It is quite difficult to find anybody running a system with less than 64M of RAM. CPUs are fast. It is 21st century, after all. Is Pike's target market 486dx33 with 8MB RAM? I doubt that.
I would argue that why can't Pike's target market be 486dx33's? I personally have tried to install pike on a 32MB CRAMFS partition on a embedded machine, and it just can't be done. This is a real pity because with things like it's easy to use HTTP stack and good networking it is an excellent choice for embedded applications.
I think real effort should go into making pike smaller, as well as making it bigger.
[jnt@rusty]~$ du -sh /sw/lib/pike/ 18M /sw/lib/pike
See what I mean?
James Tyson Director, Giant Robot Ltd http://www.giantrobot.co.nz/
/ Brevbäraren
You can make it quite a bit smaller almost without effort.
[nilsson@mahoro 7.5.12]$ bin/pike Pike v7.5 release 12 running Hilfe v3.5 (Incremental Pike Frontend)
exit
Exiting. [nilsson@mahoro 7.5.12]$ du -hs 2.3M . [nilsson@mahoro 7.5.12]$ find . . ./bin ./bin/pike ./lib ./lib/modules ./lib/modules/__builtin.pmod ./lib/modules/__builtin_dirnode.pmod ./lib/modules/files.pmod ./lib/modules/_math.pmod ./lib/modules/Gmp.pmod ./lib/modules/___Gmp.so ./lib/modules/Parser.pmod ./lib/modules/Parser.pmod/____parser.so ./lib/modules/Parser.pmod/_parser.pmod ./lib/modules/Parser.pmod/Pike.pmod ./lib/modules/Parser.pmod/C.pmod ./lib/modules/Parser.pmod/module.pmod ./lib/modules/_system.pmod ./lib/modules/ADT.pmod ./lib/modules/ADT.pmod/History.pike ./lib/modules/ADT.pmod/Stack.pike ./lib/modules/ADT.pmod/module.pmod ./lib/modules/____ADT.so ./lib/modules/_ADT.pmod ./lib/modules/Array.pmod ./lib/modules/Getopt.pmod ./lib/modules/System.pmod ./lib/modules/Thread.pmod ./lib/modules/Stdio.pmod ./lib/modules/Stdio.pmod/Readline.pike ./lib/modules/Stdio.pmod/Terminfo.pmod ./lib/modules/Stdio.pmod/module.pmod ./lib/modules/String.pmod ./lib/modules/String.pmod/module.pmod ./lib/modules/Tools.pmod ./lib/modules/Tools.pmod/Hilfe.pmod ./lib/master.pike
/ Martin Nilsson (saturator)
Previous text:
2003-10-08 11:20: Subject: time() and optimization again
RAM is quite cheap now. It is quite difficult to find anybody running a system with less than 64M of RAM. CPUs are fast. It is 21st century, after all. Is Pike's target market 486dx33 with 8MB RAM? I doubt that.
I would argue that why can't Pike's target market be 486dx33's? I personally have tried to install pike on a 32MB CRAMFS partition on a embedded machine, and it just can't be done. This is a real pity because with things like it's easy to use HTTP stack and good networking it is an excellent choice for embedded applications.
I think real effort should go into making pike smaller, as well as making it bigger.
[jnt@rusty]~$ du -sh /sw/lib/pike/ 18M /sw/lib/pike
See what I mean?
James Tyson Director, Giant Robot Ltd http://www.giantrobot.co.nz/
/ Brevbäraren
In the last episode (Sep 20), James Tyson said:
I would argue that why can't Pike's target market be 486dx33's? I personally have tried to install pike on a 32MB CRAMFS partition on a embedded machine, and it just can't be done. This is a real pity because with things like it's easy to use HTTP stack and good networking it is an excellent choice for embedded applications.
I think real effort should go into making pike smaller, as well as making it bigger.
[jnt@rusty]~$ du -sh /sw/lib/pike/ 18M /sw/lib/pike
There are a few modules that consume more than their fair share of space:
291978 lib/modules/GLUT.so* 365146 lib/modules/____Charset.so* 403126 lib/modules/_Crypto.so* 530698 lib/modules/___GTK.so* 1994722 lib/modules/Image.so*
Not sure how many of the big ones you can remove and still have a useful pike. I also seem to remember this topic coming up somewhere a couple of years ago, but I can't find it in my archives.
If you run strip on them they'll shrink significally in size.
/ Martin Nilsson (saturator)
Previous text:
2003-10-08 17:41: Subject: Re: time() and optimization again
In the last episode (Sep 20), James Tyson said:
I would argue that why can't Pike's target market be 486dx33's? I personally have tried to install pike on a 32MB CRAMFS partition on a embedded machine, and it just can't be done. This is a real pity because with things like it's easy to use HTTP stack and good networking it is an excellent choice for embedded applications.
I think real effort should go into making pike smaller, as well as making it bigger.
[jnt@rusty]~$ du -sh /sw/lib/pike/ 18M /sw/lib/pike
There are a few modules that consume more than their fair share of space:
291978 lib/modules/GLUT.so* 365146 lib/modules/____Charset.so* 403126 lib/modules/_Crypto.so* 530698 lib/modules/___GTK.so* 1994722 lib/modules/Image.so*
Not sure how many of the big ones you can remove and still have a useful pike. I also seem to remember this topic coming up somewhere a couple of years ago, but I can't find it in my archives.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
1994722 lib/modules/Image.so*
Mine is only 870kb. You might want to try stripping it.
/ Per Hedbor ()
Previous text:
2003-10-08 17:41: Subject: Re: time() and optimization again
In the last episode (Sep 20), James Tyson said:
I would argue that why can't Pike's target market be 486dx33's? I personally have tried to install pike on a 32MB CRAMFS partition on a embedded machine, and it just can't be done. This is a real pity because with things like it's easy to use HTTP stack and good networking it is an excellent choice for embedded applications.
I think real effort should go into making pike smaller, as well as making it bigger.
[jnt@rusty]~$ du -sh /sw/lib/pike/ 18M /sw/lib/pike
There are a few modules that consume more than their fair share of space:
291978 lib/modules/GLUT.so* 365146 lib/modules/____Charset.so* 403126 lib/modules/_Crypto.so* 530698 lib/modules/___GTK.so* 1994722 lib/modules/Image.so*
Not sure how many of the big ones you can remove and still have a useful pike. I also seem to remember this topic coming up somewhere a couple of years ago, but I can't find it in my archives.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
You can also remove all the .o-files from the installation.
/ Martin Nilsson (saturator)
Previous text:
2003-10-08 19:04: Subject: Re: time() and optimization again
In the last episode (Oct 08), Per Hedbor () @ Pike (-) developers forum said:
1994722 lib/modules/Image.so*
Mine is only 870kb. You might want to try stripping it.
Ah. Yes. Shrinks my 7.5.3 install from 23MB down to 17.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
On Wed, Oct 08, 2003 at 10:40:25AM -0500, Dan Nelson wrote:
291978 lib/modules/GLUT.so* 365146 lib/modules/____Charset.so* 403126 lib/modules/_Crypto.so* 530698 lib/modules/___GTK.so* 1994722 lib/modules/Image.so*
All image processing and GTK stuff is a waste of space on embedded systems (and GTK on servers without X too, I guess), IMHO :)
In my experience (mostly networking apps), I don't use anything except core modules - no graphics, no GTK, no charsets (yet), may be Array and String... well, Thread as well, but extremely rarely something else :)
Regards, /Al
pike-devel@lists.lysator.liu.se