Off-Topic > Off-Topic - Tiny Core Lounge
Benchmark: busybox sed vs GNU sed vs lua
(1/1)
jazzbiker:
Hi, brothers in Core!
Here are the results of one funny benchmark. TC10 x86 on very, very slow laptop.
Prerequisites:
--- Code: ---tce-load -i sed lua
cd /tmp
lua -e 'for i=1,65536 do io.write("1") end' > units
--- End code ---
And here are our competitors:
--- Code: ---Time busybox sed -e 's/1/2/g' units >/dev/null
real 0m 5.28s
user 0m 5.26s
sys 0m 0.00s
Time sed -e 's/1/2/g' units >/dev/null
real 0m 0.13s
user 0m 0.12s
sys 0m 0.00s
Time lua -e 'io.input("units") io.write((string.gsub(io.read("a"),"1","2")))' >/dev/null
real 0m 0.03s
user 0m 0.02s
sys 0m 0.00s
--- End code ---
Enjoy! ;)
PS: Don't be surprised by capitalized 'Time' - this is demand of our forum engine.
Rich:
Hi jazzbiker
Did you run this between each test to make sure any caching can't influence the timing:
--- Code: ---sudo cache-clear
sync
--- End code ---
If you run this twice in a row does it come out to ~5.28 secs both times:
--- Code: ---time busybox sed -e 's/1/2/g' units >/dev/null
--- End code ---
jazzbiker:
Hi, Rich!
Remark accepted - clearing cache adds about 0.1s to the "real" time (at my particular laptop), and doesn't change "user" and "sys" measurements. The main conclusion of this benchmark (for me) is, that busybox sed is heavily non-optimal serving "g" flag in the grade of O(n^2) patterns found in the same string . And the other, less noticeable but more amazing (for me) is that lua is sedding faster than GNU sed, even in the easiest tests.
--- Code: ---lua -e 'for i=1,65536 do io.write("1\n") end' > digits
Time busybox sed -e 's/1/2/g' digits >/dev/null
real 0m 0.27s
user 0m 0.26s
sys 0m 0.00s
Time sed -e 's/1/2/g' digits >/dev/null
real 0m 0.28s
user 0m 0.27s
sys 0m 0.00s
Time lua -e 'io.input("digits") io.write((string.gsub(io.read("a"),"1","2")))' >/dev/null
real 0m 0.04s
user 0m 0.03s
sys 0m 0.00s
--- End code ---
Rich:
Hi jazzbiker
--- Quote from: jazzbiker on June 06, 2021, 12:32:44 PM --- ... The main conclusion of this benchmark (for me) is, that busybox sed is heavily non-optimal serving "g" flag in the grade of O(n^2) patterns found in the same string . ...
--- End quote ---
Busybox functions are optimized for size by maximizing the amount of code shared between functions. So the fact that
they are slower is no surprise.
If you download BuildProvidesAllDatabase.sh found here:
http://forum.tinycorelinux.net/index.php/topic,24581.msg156588.html#msg156588
you will find 3 sections labeled # Execution times: that compares timing for a couple different ways of doing things.
Navigation
[0] Message Index
Go to full version