Alpha performance compared PHP and Adobe Coldfusion 2018 interpreter

[kkfin]

Re: Alpha performance compared PHP and Adobe Coldfusion 2018 interpreter

I did have time to test also other Basic language interpreters I have. This is interesting:)

BBC Basic for Windows 6.12a (repeat-until) 39 sec!!! Bravo
Purebasic 5.70 LTS(x64) 12 sec
Spiderbasic 2.2.1 under 1 sec

All tested in same machine as before others.

Who say that Basic can not be fast.

Ken

[kkfin]

Re: Alpha performance compared PHP and Adobe Coldfusion 2018 interpreter

I tested this code in Alpha Application Server in test.a5w page

<!--A5Language:Javascript-->
<%a5 
i = 0;
 while (i < 100000000){
	i++;
	}
print(i);
%>

The result was immediate under 1 sec.

Big big difference compared to xbasic.

Latest roadmap did has a mention (again) of server side javascript in AA. Lets hope it is an alternative choice one day.

[RichCPT]

Re: Alpha performance compared PHP and Adobe Coldfusion 2018 interpreter

Ken,
So, how was the first timing taken? Was it from the Control Panel Interactive window?

Was first timing from one of these places:
1) Server-Side Grid Embed (like OnGridInitialize)
2) Server-Side Grid callback function
3) Server-Side UX Embed (like OnDialogInitialize)
4) Server-Side UX callback function

If your timings were taken from one of the above then you have a good case to take back to Alpha and ask, "What is going on with the WAS? The time taken to run a tight loop in xbasic on an a5w page vs from inside a grid or UX should be vastly closer. Is there a problem in how it is yielding processor time?"

If your initial timings were taken from the Control Panel Interactive window and the above four places can run the loop in about one second then I think this case can be dismissed.

However, don't give up in finding ways to make AA run faster. I've been trying to get a couple of components to run faster under AA and so far I have had pretty good luck removing conditional expressions from server-side and client-side expressions and reducing the amount of data / controls shown in Grids and lists.

[kkfin]

Re: Alpha performance compared PHP and Adobe Coldfusion 2018 interpreter

Ken,
So, how was the first timing taken? Was it from the Control Panel Interactive window?

Was first timing from one of these places:
1) Server-Side Grid Embed (like OnGridInitialize)
2) Server-Side Grid callback function
3) Server-Side UX Embed (like OnDialogInitialize)
4) Server-Side UX callback function

If your timings were taken from one of the above then you have a good case to take back to Alpha and ask, "What is going on with the WAS? The time taken to run a tight loop in xbasic on an a5w page vs from inside a grid or UX should be vastly closer. Is there a problem in how it is yielding processor time?"

If your initial timings were taken from the Control Panel Interactive window and the above four places can run the loop in about one second then I think this case can be dismissed.

However, don't give up in finding ways to make AA run faster. I've been trying to get a couple of components to run faster under AA and so far I have had pretty good luck removing conditional expressions from server-side and client-side expressions and reducing the amount of data / controls shown in Grids and lists.

I do not think performance in a top value in Alpha and this is also true with xbasic. It is in my opinion a collection of wrapper functions currently. I think the point is in Richard post #12.

There is many ways to make performance better. And some that you can not change.

Ken

[jgrannis]

Re: Alpha performance compared PHP and Adobe Coldfusion 2018 interpreter

Latest roadmap did has a mention (again) of server side javascript in AA. Lets hope it is an alternative choice one day.

I believe that Alpha's approach to server-side javascript is already to hand it over to Node.js via calling a Node service from Xbasic.
So if something gets too hard to do with Xbasic, is for some reason much slower when using Xbasic, or maybe in the case where a nice Node module already exists to get the job done, we can do server-side javascript today.

I do remember the convenience, in the 90's, of doing a lot of server-side javascript (SSJS) with Netscape's iPlanet web servers. Never thought I would still be doing javascript on the server 20 years later.