Page 3 of 4
Re: Project: Performance Benchmarking Toolkit
Posted: Mon Nov 24, 2014 5:42 pm
by [-hh]
Dear 'Fourthworld',
you know I'm often but not always a great admirer of your doing, but I respect it very much, it's straight on. And I am, as a lot of other users, thankful for your competent help.
On occasion of crossing the
3000 posts line I am thus instructed by some other users and me to present you the virtual 3000 posts bouquet.
- The 3000 posts bouquet. Take it when crossing the line.
Thank you very much for your help, engagement and work (as the manager) for the community.
Dear Malte,
on occasion of your crossing the
2^10 posts line (good excuse for my missing your 1000 posts crossing, isn't it?) here a virtual 2^10 gift: Pi with its first 2^10 digits:
Code: Select all
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788
Re: Project: Performance Benchmarking Toolkit
Posted: Tue Nov 25, 2014 2:22 am
by FourthWorld
Very thoughtful, -hh. Thank you. Happy to be of service whenever I can.
Re: Project: Performance Benchmarking Toolkit
Posted: Wed Nov 26, 2014 11:13 am
by malte
Danke Hermann!
Re: Project: Performance Benchmarking Toolkit
Posted: Fri Nov 28, 2014 3:17 pm
by FourthWorld
Looking for ways to streamline CGI performance I made this simple script to measure boot time:
Code: Select all
#!livecode-server
put "Howdy!"
quit
...and then ran it with strace to see the system calls it makes:
Code: Select all
strace -v -o lctrace.txt ./test.lc
Looking at the resulting output file I was surprised to find that more than 3/4 of all system calls during boot of the SERVER engine are related to FONT management.
I realize that LC Server now also provides graphics handling, so I can appreciate the need for the lengthy font init. But for apps where fonts will never be used, should there be a way to turn that off? Maybe with a flag in the command line?
3/4 of boot instructions seems worth trimming if we can.
Should I submit a request for an optional -f flag for LC Server to turn off font init?
Or would it be more helpful to be able turn off all graphics initialization with something like -g?
Re: Project: Performance Benchmarking Toolkit
Posted: Fri Nov 28, 2014 3:27 pm
by peter-b
FourthWorld wrote:Looking at the resulting output file I was surprised to find that more than 3/4 of all system calls during boot of the SERVER engine are related to FONT management.
Lazy font initialisation is already on our list of desired improvements for server performance in CGI contexts.
Re: Project: Performance Benchmarking Toolkit
Posted: Fri Nov 28, 2014 4:27 pm
by FourthWorld
peter-b wrote:FourthWorld wrote:Looking at the resulting output file I was surprised to find that more than 3/4 of all system calls during boot of the SERVER engine are related to FONT management.
Lazy font initialisation is already on our list of desired improvements for server performance in CGI contexts.
Good to hear - thanks. Should I submit this as an RQCC request to help with tracking or is that not needed at this time?
Re: Project: Performance Benchmarking Toolkit
Posted: Fri Nov 28, 2014 4:34 pm
by peter-b
FourthWorld wrote:peter-b wrote:FourthWorld wrote:Looking at the resulting output file I was surprised to find that more than 3/4 of all system calls during boot of the SERVER engine are related to FONT management.
Lazy font initialisation is already on our list of desired improvements for server performance in CGI contexts.
Good to hear - thanks. Should I submit this as an RQCC request to help with tracking or is that not needed at this time?
Sure, that would be great.
Re: Project: Performance Benchmarking Toolkit
Posted: Fri Nov 28, 2014 10:15 pm
by FourthWorld
Re: Project: Performance Benchmarking Toolkit
Posted: Fri Nov 28, 2014 10:17 pm
by FourthWorld
@Peter - another thing I saw in the strace output was a lot of lines line this:
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
What is nohwcap, and why would the engine keep looking for it over and over after it's already been told it isn't there?
Re: Project: Performance Benchmarking Toolkit
Posted: Tue Dec 02, 2014 11:40 am
by peter-b
FourthWorld wrote:@Peter - another thing I saw in the strace output was a lot of lines line this:
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
What is nohwcap, and why would the engine keep looking for it over and over after it's already been told it isn't there?
See
man ld.so.
Re: Project: Performance Benchmarking Toolkit
Posted: Wed Dec 03, 2014 1:57 am
by FourthWorld
Thanks, Peter. From the man page:
/etc/ld.so.nohwcap When this file is present the dynamic linker will
load the non-optimized version of a library, even
if the CPU supports the optimized version.
So to this layman it seems those calls are forcing non-optimized performance - do I misunderstand that?
Re: Project: Performance Benchmarking Toolkit
Posted: Wed Dec 03, 2014 9:40 am
by peter-b
FourthWorld wrote:Thanks, Peter. From the man page:
/etc/ld.so.nohwcap When this file is present the dynamic linker will
load the non-optimized version of a library, even
if the CPU supports the optimized version.
So to this layman it seems those calls are forcing non-optimized performance - do I misunderstand that?
The opposite. The strace output indicates that ld.so.linux is looking for /etc/ld.so.nohwcap, but doesn't find it (ENOENT). Since /etc/ld.so.nohwcap is not present, ld.so.linux procedes to load the optimized version. I.e. the call's
failure forces
optimized performance (if available).
I'm pretty certain this behaviour is a Debianism. ld.so on my Fedora 20 system doesn't do this.
Re: Project: Performance Benchmarking Toolkit
Posted: Wed Dec 03, 2014 10:27 pm
by FourthWorld
Thanks for the explanation, Peter. I have to admit it's over my head: it succeeds in not impairing performance because it fails to find what it's looking for - seems simpler to this layman to just not look for it.
Linux is indeed a rich learning opportunity....
compress / decompress
Posted: Thu Dec 04, 2014 5:22 pm
by malte
Code: Select all
on mouseUp
local tString,tTest
repeat 1000000
put "asd" & cr after tString
end repeat
put the millisecs into tTest
put compress(tString) into tString
answer the millisecs - tTest
put the millisecs into tTest
put decompress(tString) into tString
answer the millisecs - tTest
end mouseUp
This is actually quite nice:
6.5:
compress: 40 ms
decompress: 10 ms
7.0.1 RC3:
compress: 46 ms
decompress: 4 ms
So while compressing takes a little longer, decompressing got quite a bit faster!
Re: Project: Performance Benchmarking Toolkit
Posted: Thu Dec 04, 2014 5:26 pm
by malte
Code: Select all
on mouseUp
local tString,tTest
repeat 1000000
put "asd" & cr after tString
end repeat
put the millisecs into tTest
put base64Encode(tString) into tString
answer the millisecs - tTest
put the millisecs into tTest
put base64Decode(tString) into tString
answer the millisecs - tTest
end mouseUp
6.5
encode: 26ms
decode: 48ms
7.0.1 RC3
encode: 30ms
decode: 35ms