Comparison of Speed of LiveCode with PHP

Tue Nov 25 06:16:41 EST 2014

Eons ago I created a library to do FastCGI from LiveCode. Even though my
library supported multiplexing stuff LiveCode could not respond to more
than one user at a time. If LC was multithreaded or had co-routines or
fibers or whatever lightweight gizmo they could create in Scotland to let
us run more than one thing at the same time then FastCGI would be viable.

As it is, FastCGI is worse than CGI for LC because with CGI we can answer
more than one user at the same time by spawning new processes. With
FastCGI, while the request was being processed, no other request would be
answered. Thats not a FastCGI limitation, the protocol is way smarter than
CGI you receive all requests on the same port and you're supposed to
fork(). Since we have nothing like forking on LC, we're dead on that front.

The main issue is that without multithread, fork or something similar that
would allow us to delegate some execution of handlers to another context
and thus enable us to execute multiple stuff at the same time we can't
implement FastCGI.

On Tue, Nov 25, 2014 at 8:40 AM, Simon Smith <hello at simonsmith.co> wrote:

> 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
> _______________________________________________
> 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.