Tiny Core Base > Micro Core

[Solved] proposal to clean up the tc-config script (maybe speed it up a little)

<< < (2/2)

nick65go:
@curaga: sorry for "ifgrep". my mouse pointer random jumped into another aterm window/row and edited the tc-config by mistake/ live, without me note it.
@ paul_123: you are right about to measure the "improvment" pieces by pieces. I did it in the past (rudimentary) and it is about 2-7 seconds, depending on HDD speed, tc version (biger kernels now) etc. Lets say I boot the "laptop" 10 times/day, i ussualy just suspend it in RAM, but crappy battery can deplete in the mean time. So if I gain 2 seconds/boot, then is not worth the few hours spend testing the "improvments" which could break other CPU arhitecture not tested (arm vs. x86).The fact that you ask me to do the test myself, means that you already did some test, and you concluded that tc-config is in the best shape now  :P OK, just say it so clearly, no problem.

The proposal was more about better undestanding the documentation, audit the code again, because new version busybox bugs, what was OK in the past could be not OK now.

To make TC more modular as andyj said; i will "borrow" few ideas from him in my "remix".
I am not a programmer, so PDP-8 talk about git (public work) is no way for me. Forget about it.The problem with remix is that ussualy will be optimized for special purposes (QEMU virtual machine, UEFI only real laptop).

nick65go:

--- Quote from: andyj on August 12, 2020, 03:46:21 PM ---Sounds like this http://forum.tinycorelinux.net/index.php/topic,23835.0.html again. Good luck.

--- End quote ---
looking at your work, i saw max 47 parameters in tc-config (a script of 17KB), to be read from /proc/cmdline and evaluated.
On average I assume any user use max 3-7 variables (lets say 5), because some options can be started from onboot (kmap, locale, windows-manager), others from /opt/bootsync.sh, ondemand, /home/user/.Xd, or others are mutually exclusive, such as:
- nodhcp/nfsmount*/tftplist*/httplist*/aoe*/ntpserver*
- xsetup/xvesa*/xonly/text
- base/showapps
So STATISTICALY (empiric): near no improvement in speed to grab (from RAM) and then parse (in RAM) only few variable (max. 5) commonly used day by day.
And for each variable usually is just a short action, such as export a value, load a kernel module.
Even we loose speed when is something interactive such as add/create user, wait for a USB, access the network.

It is all about cleaner infrastructure, as you said. And maybe better documentation as I said. If developers think is worth their time.

@forum moderator: you can mark this subject as [closed/solved]. thank you.

Rich:
Hi nick65go

--- Quote from: nick65go on August 12, 2020, 02:46:19 PM --- ... sample of bloat /fat code:

--- Code: ---USER="tc"
...
if [ -n "$USER" ]; then
    if ! grep "$USER" /etc/passwd >/dev/null; then addUser; fi
else
    USER="tc"
fi
--- End code ---
...
--- End quote ---
At first glance, it might appear testing $USER for non-zero length is unnecessary since it is set to  "tc"  at the beginning of the script.
That would leave only this:

--- Code: ---USER="tc"
...

if ! grep "$USER" /etc/passwd >/dev/null; then addUser; fi
--- End code ---
That was my initial thought. Of course it was wrong. After $USER is set to  "tc",  it can be overridden with the  user=  boot code.
If someone enters this:

--- Code: ---user=""
--- End code ---
or this

--- Code: ---user=
--- End code ---
then $USER becomes a zero length (empty) string. So the only "bloat" is the  USER="tc"  at the beginning of the script.



--- Quote --- ... many action grouped together and in the back ground + in paralel?
/sbin/loadcpufreq 2>/dev/null &
/sbin/ifconfig lo 127.0.0.1 up && /sbin/route add 127.0.0.1 lo &
chmod u+s /bin/busybox.suid /usr/bin/sudo
modprobe -q squashfs 2>/dev/null

or similar:
[ -n "$XSETUP" ] && touch /tmp/xsetup_requested
[ -n "$XVESA" ]  && sed -i 's/1024x768x32/'"$XVESA"'/' /home/"$USER"/.xsession 2>/dev/null ...
--- End quote ---
There are 3 things (that I could think of) to keep in mind when deciding to background something
1. You want to make sure actions that depend on other actions are not backgrounded at the same time.
2. Backgrounding actions for speed is most effective when they have to wait for other slower operations anyway.
3. Backgrounding many actions capable of running at full speed could slow them down if the kernel needs to switch between them.

Navigation

[0] Message Index

[*] Previous page