Project: Performance Benchmarking Toolkit

This forum is a working group for community contributors to the LiveCode IDE included in the main LiveCode distribution.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Project: Performance Benchmarking Toolkit

Post by [-hh] » Mon Nov 24, 2014 5:42 pm

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.
3000posts.jpg
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
Thank you very much for your help and engagement in the community.
shiftLock happens

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Tue Nov 25, 2014 2:22 am

Very thoughtful, -hh. Thank you. Happy to be of service whenever I can.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by malte » Wed Nov 26, 2014 11:13 am

Danke Hermann! :-)

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Fri Nov 28, 2014 3:17 pm

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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

peter-b
Posts: 182
Joined: Thu Nov 20, 2014 2:14 pm
Location: LiveCode Ltd.

Re: Project: Performance Benchmarking Toolkit

Post by peter-b » Fri Nov 28, 2014 3:27 pm

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.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Fri Nov 28, 2014 4:27 pm

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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

peter-b
Posts: 182
Joined: Thu Nov 20, 2014 2:14 pm
Location: LiveCode Ltd.

Re: Project: Performance Benchmarking Toolkit

Post by peter-b » Fri Nov 28, 2014 4:34 pm

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. :)
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Fri Nov 28, 2014 10:15 pm

Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Fri Nov 28, 2014 10:17 pm

@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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

peter-b
Posts: 182
Joined: Thu Nov 20, 2014 2:14 pm
Location: LiveCode Ltd.

Re: Project: Performance Benchmarking Toolkit

Post by peter-b » Tue Dec 02, 2014 11:40 am

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.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Wed Dec 03, 2014 1:57 am

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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

peter-b
Posts: 182
Joined: Thu Nov 20, 2014 2:14 pm
Location: LiveCode Ltd.

Re: Project: Performance Benchmarking Toolkit

Post by peter-b » Wed Dec 03, 2014 9:40 am

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.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by FourthWorld » Wed Dec 03, 2014 10:27 pm

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....
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

compress / decompress

Post by malte » Thu Dec 04, 2014 5:22 pm

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!

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: Project: Performance Benchmarking Toolkit

Post by malte » Thu Dec 04, 2014 5:26 pm

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

Locked

Return to “IDE Contributors”