Comparison of Speed of LiveCode with PHP

Tue Nov 25 05:40:56 EST 2014

The benefit of FastCGI would be that the Fast cgi instance would always be
running and would not need to be restarted every time a .lc script is
parsed saving on the execution time.

Even as a CGI process, LiveCode should already be able to run behind a load
balancing server,

Kind Regards
Simon

On Tue, Nov 25, 2014 at 10:23 AM, Peter W A Wood <peterwawood at gmail.com>
wrote:

> Hi Andre
>
> I agree with your comments on the appropriateness of the tests. I’ll give
> some thought to incorporating more I/O based tests.
>
> Do you think that having FastCGI support so that LiveCode could be run
> behind a load balancing server would be an improvement from a scalability
> point of view.
>
> Regards
>
> Peter
>
> > On 24 Nov 2014, at 23:42, Andre Garzia <andre at andregarzia.com> wrote:
> >
> > Hi Peter,
> >
> > Thanks for your testing!
> >
> > I think we're approaching this performance issue wrong. Most webapps will
> > be I/O bound and not CPU bound. Calculations are not the most common
> thing
> > going on but I/O in the sense of reading and writing from database and
> > files are. Also the only way to deal with structured data in memory in a
> > straight forward way is LiveCode multilevel arrays but there is no
> built-in
> > way to serialize these arrays for consumption outside of LiveCode. For
> > example, a common thing these days is to have your client-side HTML5 code
> > calling back your server-side code for more information which is normally
> > presented in JSON but LiveCode has no built-in function for JSON encoding
> > and decoding, so both operations happen in pure transcript (or whatever
> > they are calling it these days) which will make it really slow.
> >
> > If we want LiveCode to have better performance we need ways to improve
> I/O.
> > Things that would be good and have a real impact out of the box:
> >
> > - JSON and XML encode and decode functions in the engine.
> > - Non-blocking DB routines
> >
> >
> > A different issue is scalability. Right now, LiveCode Server works in CGI
> > mode which is very straight forward but it is not the most scalable thing
> > under the sun. When I say scale, I am not saying things such as serving
> > 5.000 users. Serving a couple thousand users is easy. I am saying serving
> > some hundred thousand users with complex server side logic, afterall
> doing
> > 100.000 hello worlds is easy.
> >
> > PHP is going thru lots of revolutions in the form of the Facebook
> > initiatives such as "hack" (new PHP variation), that VM they created and
> > the little compiler they created which I forgot the name. The PHP
> > developers are also pushing PHPNG and other gizmos. Even current
> generation
> > PHP is not usually server with CGI technology.
> >
> > Ruby, Node, Python, Clojure, Java, none are served with CGI. Most of them
> > could be used as CGI but no one is using them this way. CGI is easy but
> it
> > is not scalable. Imagine that if you were serving 10.000 concurrent
> > requests on your little server farm, you're have a collection of 10.000
> > LiveCode server processes between your servers.
> >
> > What we need is something like Python WSGI or a non-blocking engine such
> as
> > Node. Then we could with a simple pool of couple LiveCode engine
> instances
> > serve a lot of people.
> >
> > On Mon, Nov 24, 2014 at 1:33 AM, Peter W A Wood <peterwawood at gmail.com>
> > wrote:
> >
> >> In a previous email Richard Gaskin, the LiveCode Community Manager,
> wrote
> >> "Given the role of memory and performance for scaling, if we want to
> see LC
> >> Server taken seriously as a professional server tool we need to identify
> >> and eliminate any significant performance difference between it and
> PHP.”
> >>
> >> I thought that it would be worth spending a little time to compare the
> >> speed of LiveCode against the speed of PHP. I came up with a test based
> >> loosely on Carl Sassenrath’s Rebol Speed Script (
> >> http://www.rebol.com/cgi-bin/blog.r?view=0506 ). I have found it a
> useful
> >> base for writing comparative scripts (either comparing languages on a
> >> single machine or comparing machines using a single language). It is far
> >> from perfect in a multi-tasking environment but I believe provides
> decent
> >> comparative data.
> >>
> >> I have attached two scripts, speedtest.lc and speedtest.php. I’m sure
> >> that both could be improved significantly and welcome such improvements.
> >> The results of running the two scripts on my machine, LiveCode
> 7.0.0-rc-3
> >> and PHP 5.5.14 are:
> >>
> >> Schulz:LiveCodeServer peter$ ./speedtest.lc
> >> LiveCode Speed Test Started
> >> The CPU test took:             2851 ms
> >> The Memory test took:       3656 ms
> >> The File System test took:  1975 ms
> >> LiveCode Speed Test Finished
> >>
> >> Schulz:LiveCodeServer peter$ ./speedtest.php
> >> PHP Speed Test Started
> >> The CPU test took:              3921 ms
> >> The Memory test took:       1200 ms
> >> The File System test took:  666 ms
> >> PHP Speed Test Finished
> >>
> >> So it seems the LiveCode has the edge on PHP when it comes to
> calculations
> >> but not on memory access or file access.
> >>
> >> The memory test relies on using arrays, I'm not sure if that is the best
> >> way to test memory access.
> >>
> >> Regards
> >>
> >> Peter
> >>
> >> Speedtest.lc
> >>
> >> #!livecode
> >>
> >> if the platform = "MacOS" then
> >>  set the outputLineEndings to "lf"
> >> end if
> >>
> >> put "LiveCode Speed Test Started" & return
> >>
> >> ##cpu test
> >> put the millisecs into tStart
> >> repeat with i = 1 to 10000000
> >>  put sqrt(exp(i)) into tTemp
> >> end repeat
> >> put the millisecs into tEnd
> >> put "The CPU test took:        " && tEnd - tStart && "ms" & return
> >>
> >> ##Memory Access
> >> put the millisecs into tStart
> >> repeat with i = 1 to 1000000
> >>  put random(255) into tMem[i]
> >> end repeat
> >> put the millisecs into tEnd
> >> put "The Memory test took:     " && tEnd - tStart && "ms" & return
> >>
> >> ##Filesystem
> >> open file "test.tmp"
> >> put the millisecs into tStart
> >> repeat with i = 1 to 100000
> >>  write "This is a test of the write speed" && random(255) to file
> >> "test.tmp"
> >>  read from file "test.tmp" for 1 line
> >> end repeat
> >> put the millisecs into tEnd
> >> put "The File System test took:" && tEnd - tStart && "ms" & return
> >> delete file "test.tmp"
> >>
> >> ##Finish
> >> put "LiveCode Speed Test Finished" & return
> >>
> >> Speedtest.php
> >>
> >> #!/usr/bin/php
> >>
> >> <?php
> >>
> >> print "PHP Speed Test Started\n";
> >>
> >> //cpu test
> >> $start = microtime(true);
> >> for( $i = 0; $i < 10000000; $i++ ) {
> >>  $temp = sqrt(exp($i));
> >> }
> >> $end = microtime(true);
> >> $time = ($end - $start) * 1000 + 0.5;
> >> printf("The CPU test took:         %5.0f ms\n", $time);
> >>
> >> //Memory Access
> >> $start = microtime(true);
> >> for( $i = 0; $i < 1000000; $i++ ) {
> >>  $mem[i] = rand(0, 255);
> >> }
> >> $end = microtime(true);
> >> $time = ($end - $start) * 1000 + 0.5;
> >> printf("The Memory test took:      %5.0f ms\n", $time);
> >>
> >> //Filesystem
> >> $file = fopen("test.tmp", "w+");
> >> $start = microtime(true);
> >> for( $i = 0; $i < 100000; $i++ ) {
> >>  rewind($file);
> >>  fwrite($file, "This is a test of the write speed".rand(0,255));
> >>  fread($file, 34);
> >> }
> >> $end = microtime(true);
> >> $time = ($end - $start) * 1000 + 0.5;
> >> printf("The File System test took: %5.0f ms\n", $time);
> >> unlink("test.tmp");
> >>
> >> //Finish
> >> print "PHP Speed Test Finished\n";
> >>
> >> ?>
> >>
> >>
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> >
> >
> > --
> > http://www.andregarzia.com -- All We Do Is Code.
> > http://fon.nu -- minimalist url shortening service.
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

-- 

*Simon Smith*
*seo, online marketing, web development*

w. http://www.simonsmith.co
m. +27 83 306 7862