CGI’s: AppleScript or Frontier?

Comparing scripting environments for CGI development

By Mason Hale

In a previous article, “Scripting the Web with Frontier”, I introduced you to writing CGI scripts using UserLand Frontier. In that article, I argued that Frontier was an excellent alternative for webmasters who felt forced to choose between the poor performance of AppleScript and the steep learning curve of C because Frontier is easier to use than C yet generally performs faster than AppleScript, especially when used to create CGI applications. That argument became even more true when a PowerPC-native Frontier was released for public beta-testing in late October. Like dropping a bigger engine into a hot rod, script execution instantly becomes much faster - in some cases up to six time faster. With this boost in speed on PowerPC machines, Frontier is closing the gap on C - offering both ease-of-use and excellent performance - while further increasing its lead on AppleScript.

Despite the proven benefits of using Frontier to write CGI applications, many webmasters still are developing their CGIs in AppleScript. This inspired me to look a bit more closely at the differences between CGI applications written in Frontier and those in AppleScript, primarily focusing on performance issues. In this article I will share the results of some of my recreational performance testing, and explain some of the different situations that affect performance.

Since I am the author of the Frontier CGI Framework, a set of scripts that enhance CGI development in Frontier, you could understandably question my objectivity in doing such a comparison. On the other hand, since I have done a great deal of CGI development in both environments, I am also one of the few people qualified to do such a comparison. In either case it is not my intent to discount AppleScript as a scripting environment. I think it is a great product and an important technology. I just don’t believe it is well-suited to the specific task of CGI development.

Performance

Performance is crucial to CGI applications running on busy servers. The more processing time a request takes, the more likely a user is to give up and move on to another site.

I’ve often been asked if Frontier is faster than AppleScript. The truth is, when comparing built-in verbs in AppleScript and the non-native version of Frontier, the performance is surprising similar. I ran a series of informal tests to compare the performance of AppleScript, non-native Frontier and native Frontier when running equivalent scripts. The scripts are based on the sample scripts from Frontier’s object database. All tests were run on a Power Macintosh 7200/75 with 16 MB RAM. Execution time is measured in ticks (sixtieths of seconds).

The first test script performs simple integer arithmetic using built-in commands in both the AppleScript and UserTalk versions. The actual scripts are functionally identical.

Test 1: Integer Arithmetic (AppleScript)
set x to 0
repeat with i from 1 to 1000
 set x to x + (12 + 99 - 37 / 84)
end

Test 1: Integer Arithmetic (UserTalk)
x = 0
for i = 1 to 1000 
 x = x + (12 + 99 - 37 / 84)

AppleScript took 111 ticks to complete the first test, while the non-native Frontier took 103 ticks. The PowerPC-native Frontier ran the same script in just 17 ticks. This first test really shows how close the non-native Frontier and AppleScript were - and the tremendous difference the native version makes.

The second test demonstrates the repeated calling of a local subroutine.

Test 2: Subroutine Call (AppleScript)
set y to 10
on moof (x)
 return (x * 2)
end
repeat with i from 1 to 1000
 set y to moof (y)
end

Test 2: Subroutine Call (UserTalk)
y = 10
on moof (x) 
 return (x * 2)
for i = 1 to 1000 
 y = moof (y)

AppleScript blew the doors of the non-native Frontier in the second test coming in at 85 ticks to Frontier’s 272 ticks. However, the PowerPC-native Frontier handily won with a time of 47 ticks.

The third script compares the performance of commands from an external Scripting Addition to a built-in Frontier verb. I compared the speed of Frontier’s built-in clock.now verb to the equivalent current date Scripting Addition.

Test 3: Built-in verb vs. Scripting Addition (UserTalk)
for i = 1 to 100 
 y = clock.now ()


Test 3: Built-in verb vs. Scripting Addition (AppleScript)

repeat with i from 1 to 100
 set y to current date
end repeat

It took AppleScript 113 ticks to complete this test, while the non-native Frontier took 17 ticks and the native Frontier took 5 ticks. This illustrates a crucial point in determining the speed of a script. Built-in commands are faster than commands loaded from external code fragments. Because AppleScript has few built-in verbs and relies heavily on Scripting Additions to extend the language, the use of external commands like “current date” is quite common.

In the fourth example the script checks the existence of a file. Frontier uses a built-in verb “file.exists”, while AppleScript communicates with the scriptable Finder via AppleEvents.

Test 4: Built-in verb vs. Apple Event (AppleScript)
set x to 0
tell application "Finder"
 repeat with i from 1 to 10
 if exists alias "Macintosh HD:SimpleText" then
 set x to x + 1
 end if
 end repeat
end tell

Test 4: Built-in verb vs. Apple Event (UserTalk)
local (x = 0)
for i = 1 to 10 
 if file.exists ("Macintosh HD:SimpleText") 
 x++

Inter-application communication can really slow things down. Each cross-application Apple Event adds approximately 1/4 second to the processing time of the script. Frontier suffers the same slowdowns when sending Apple Events to other applications, but because more commands are available, external applications are relied on less often.

The results of the fourth test bear this out. While the native and non-native Frontier applications finished in 3 ticks and 7 ticks respectively, AppleScript took 140 ticks to perform the same task using the scriptable Finder.

My final test was “real world” example, based on the “test.cgi” script that is distributed with MacHTTP. This script uses no scripting additions and doesn’t perform any cross-application communication. So it is a pretty good example of a common CGI script using built-in verbs.

Test 5: Test CGI (AppleScript)

property crlf : (ASCII character 13) & (ASCII character 10)

--this builds the normal HTTP header for regular access
property http_10_header : "HTTP/1.0 200 OK" & crlf & ¬
 "Server: MacHTTP" & crlf & "MIME-Version: 1.0" & ¬
 crlf & "Content-type: text/html" & crlf & crlf

on cgiScript (path_args, http_search_args, username, ¬
 password, from_user, client_address, server_name, ¬
 server_port, script_name, content_type, referer, ¬
 user_agent, action, action_path, post_args, method, ¬
 client_ip, full_request)
 
 try --wrap the whole script in an error handler
 return http_10_header & "<title>Test CGI</title>" & ¬
 "<h2>Test CGI</h2><u>CGI arguments sent:</u>" & ¬
 "<br><b>path:</b> " & path_args & ¬
 "<br><b>search:</b> " & http_search_args & ¬
 "<br><b>post_args:</b> " & post_args & ¬
 "<br><b>method:</b> " & method & ¬
 "<br><b>address:</b> " & client_address & ¬
 "<br><b>user:</b> " & username & ¬
 "<br><b>password:</b> " & password & ¬
 "<br><b>from:</b> " & from_user & ¬
 "<br><b>server_name:</b> " & server_name & ¬
 "<br><b>server_port:</b> " & server_port & ¬
 "<br><b>script_name:</b> " & script_name & ¬
 "<br><b>referer:</b> " & referer & ¬
 "<br><b>user agent:</b> " & user_agent & ¬
 "<br><b>content_type:</b> " & content_type & crlf
 on error msg number num
 return http_10_header & "Error " & num & ", " & msg
 end try
end caller

repeat with i from 1 to 10
cgiScript ("aaa", "bbb", "ccc", "ddd", "eee", ¬
 "fff", "ggg", "hhh", "iii", "jjj", "kkk", ¬
 "lll", "mmm", "nnn", "ooo", "ppp", "qqq", "rrr")
end repeat


Test 5: Test CGI (UserTalk)

on cgiScript (pathArgs, httpSearchArgs, username, \
 password, fromUser, clientAddress, serverName, \
 serverPort, scriptName, contentType, referer, \
 userAgent, action, actionPath, postArgs, method, \
 clientIp, fullRequest) 
 
 try 
 return (webServer.httpHeader () + \
 "<title>Test CGI</title><h2>Test CGI</h2>" + \
 "<u>CGI arguments sent:</u>" + \
 "<br><b>path:</b> " + pathArgs + \
 "<br><b>search:</b> " + httpSearchArgs + \
 "<br><b>post_args:</b> " + postArgs + \
 "<br><b>method:</b> " + method + \
 "<br><b>address:</b> " + clientAddress + \
 "<br><b>user:</b> " + username + \
 "<br><b>password:</b> " + password + \
 "<br><b>from:</b> " + fromUser + \
 "<br><b>server_name:</b> " + serverName + \
 "<br><b>server_port:</b> " + serverPort + \
 "<br><b>script_name:</b> " + scriptName + \
 "<br><b>referer:</b> " + referer + \
 "<br><b>user agent:</b> " + userAgent + \
 "<br><b>content_type:</b> " + contentType + cr + lf)
 else 
 return (webServer.httpHeader () + "Error " + tryError)
 
local (i)
for i = 1 to 10 
 cgiScript ("aaa", "bbb", "ccc", "ddd", "eee", "fff", "ggg", \
 "hhh", "iii", "jjj", "kkk", "lll", "mmm", "nnn", "ooo", \
 "ppp", "qqq", "rrr")

As expected, the AppleScript and non-native version of Frontier performed similarly. The AppleScript CGI test finished in 69 ticks, beating out Frontier at 74 ticks. Native Frontier won again with 14 ticks. A summary of the timing results for all tests is shown in Table 1.

AppleScript Frontier 68K Frontier PPC

Integer Arithmetic 111 103 17

Subroutine Call 85 272 45

Built-in vs. OSAX 113 17 5

Built-in vs. AE 140 7 3

Test CGI 69 74 14

Table 1. Comparison of execution times (all times in 1/60 second)

Multi-threading

Beyond straight script execution, another factor can significantly affect the speed at which a given script runs: multi-threading. In the exponentially-growing world of the internet, it is common for the average web server to receives thousands of requests a day. It is also quite likely that two clients will request the exact same file at the exact same time. If the requested file happens to be your CGI script, it will have to deal with two concurrent requests.

AppleScript is not multi-threaded, and handles multiple concurrent requests by placing them into a queue. Unfortunately, AppleScript processes events on a last-in first-out basis - so the latest event received is the first to be processed. To put it another way, on a very busy server, the first person to call the CGI may very well be the last person to receive the results. This can result in every single request timing out if new requests keep forcing older ones further back in the queue.

Frontier is fully multi-threaded. Every new request spawns a new thread automatically. This means that incoming event are processed immediately and do not prevent processing of earlier requests.

A more subtle, but still important performance consideration is the fact that all Frontier-based CGI’s are hosted by a single application. In the cooperative multi-tasking Mac OS, applications must cooperatively share processing time. Adding a new, separate application for each CGI creates more overhead to manage the sharing of processor time among the competing applications and eventually slows down all the applications. Consolidating all CGI scripts into Frontier’s object database eliminates this overhead.

Conclusion

Being PowerPC-native and multi-threaded clearly gives Frontier the performance advantage over AppleScript. However, even if AppleScript were multi-threaded and native, its reliance on Scripting Additions and external applications to perform its functions severely limit performance, and thus limit its usefulness as a development environment for CGI applications.

URL’s

Native Frontier Public Beta release:

http://www.hotwired.com/ userland/yabbadabba/nativefrontierpublicbe_390.html

Frontier CGI Scripting: http://www.webedge.com/frontier/

Aretha Website: http://www.hotwired.com/userland/aretha/