Re: Comparison of Speed of LiveCode with PHP
Geoff Thanks for your input. I think you are correct that the memory access comparison isn’t fair. I don’t have time right now but I’ll try to come up with a better comparison. I’m not convinced that the file comparison is fair. If LiveCode is appending the data to the file rather than overwriting the existing data then it is at a disadvantage. I’ll look a little deeper into this aspect too, once I get the time. Regards Peter On 24 Nov 2014, at 23:31, Geoff Canyon gcan...@gmail.com wrote: My PHP is weak, but if the memory access test is a regular array, then comparing it to a livecode array is somewhat apples and oranges, since LC is really a hash. But on the other hand, there's no way to do a simple array in LC, so it's not like you can do better. For the file access test, your test is pretty much apples to apples, but it would be interesting to compare it to URL access: build the whole string and write it out, then read the whole thing in and split it. That wouldn't be a fair comparison, but it would be interesting. gc ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Comparison of Speed of LiveCode with PHP
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 an...@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 peterwaw...@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 1000 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 100 put
Re: Comparison of Speed of LiveCode with PHP
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 peterwaw...@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 an...@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 peterwaw...@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.
Re: Comparison of Speed of LiveCode with PHP
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 he...@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 peterwaw...@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 an...@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 peterwaw...@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 (
Re: Comparison of Speed of LiveCode with PHP
On Tue, Nov 25, 2014 at 5:16 AM, Andre Garzia an...@andregarzia.com wrote: co-routines mmm, co-routines... ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Comparison of Speed of LiveCode with PHP
My PHP is weak, but if the memory access test is a regular array, then
comparing it to a livecode array is somewhat apples and oranges, since LC
is really a hash. But on the other hand, there's no way to do a simple
array in LC, so it's not like you can do better.
For the file access test, your test is pretty much apples to apples, but it
would be interesting to compare it to URL access: build the whole string
and write it out, then read the whole thing in and split it. That wouldn't
be a fair comparison, but it would be interesting.
gc
On Sun, Nov 23, 2014 at 9:33 PM, Peter W A Wood peterwaw...@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 1000
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 100
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 10
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 1000; $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 100; $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 10; $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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Comparison of Speed of LiveCode with PHP
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 peterwaw...@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 1000 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 100 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 10 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
Comparison of Speed of LiveCode with PHP
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 1000
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 100
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 10
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 1000; $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 100; $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 10; $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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
