1. 2.4 versus 2.5 as CGI
Hi,
Any obvious advantages from 2.5 over 2.4 used as CGI?
Also, anyone using FASTCGI with the interpreter?
Thank you
JG
2. Re: 2.4 versus 2.5 as CGI
Julio C. Galaret Viera wrote:
> Any obvious advantages from 2.5 over 2.4 used as CGI?
There is crash_routine() in v2.5 that allows programs to perform an action when
runtime errors occur. For example, if your CGI application were to crash, you
could have it call crash_routine() that could send you an email of the error dump
file, or etc. Euphoria now comes conveniently packaged with "exwc.exe", which is
best for Windows CGI with Euphoria; previously you had to build your own with the
"Makecon" tool thus wasting time.
The problem with v2.5 and later is loading speed. Euphoria doesn't load programs
quickly anymore because all of the source files are scanned and parsed before
execution actually begins. The front-end (parser, etc.) is now written in 100%
Euphoria then translated to C, so that contributes too. The benefit of this is
Euphoria now catches most or all type checking and uninitialized variable
beforehand. So poorly tested/examined programs and libraries, written with older
versions could fail on v2.5, since improper usage of data types and/or unassigned
variables could have gone undetected by the tester(s) and programmer(s). Since
the front-end, translator, binder were re-written in Euphoria, many subtle bugs
have been found then fixed and better compatability between the products now
exists. This basically allows RDS to implement new features easier, fix more bugs
faster, save time and money, thus improving their overall productivity. This fact
can inadvertently benefit us with more frequent releases, continued free and
public domain interpreters, and possibly even cheaper future product pricing on
advanced tools and services!
Loading performance varies on each platform since the Euphoria interpreters were
built with different compilers (with Euphoria, GCC for Linux & FreeBSD produce
faster executables than Watcom for DOS & Windows); but an honest estimate would
be between 5 to 10 times slower than before, but since all the code is source is
parsed at once, it could seem as much as 20 times slower than before. This means
that a huge interpreted application like Judith's Enhanced IDE can take a few
seconds longer to load on today's Pentium 4 or a few "minutes" longer on
yesterday's 386 and 486. However, with very old systems it's usually better to
translate/compiled or bind very large applications than to wait forever for them
to load. Even with v2.4 and older, loading very large applications on very old
systems can take 10 to 20+ seconds, which is still to long to wait! If compiled
or bound, there wouldn't be any parsing so loading can be much quicker.
Despite the lousy loading performance, execution performance has somehow
magically improved since v2.4 and all other releases. This performance is evident
with all computers on all platforms, but only once the program has actually
loaded 
. Except for the 10 to 20 percent degrade in recrusive call performance
with single tasked applications (which Rob is planning to minimize later with
optimizations), I hope and suspect that both execution and loading performance
will futher improve slightly for the next release due to removing bug
workarounds, further optimizations, better compiler options, and compiling with
latest Open Watcom and GCC C/C++ compilers. If RDS decides against compressing
their executables, *initialization* could become significantly faster on very old
machines since it wouldn't have to decompress the "real" program size into
memory, thus giving an illusion of faster program loading when it's really just
the interpreter initilizing faster. Additionally, uncompressed Euphoria
interpreter exectuables can save between 50 to 250+ KB of memory (depending on
compression ratio and unpacked size of the interpreters), which maybe could help
counterbalence the slightly increased memory requirements for optimizing recruive
call performance in the next release?
Regards,
Vincent
3. Re: 2.4 versus 2.5 as CGI
Refering to what Vincent said about parsing times, I found it alot easier to
upload/use a shrouded file and the backend. There are a few reasons;
- Parsing time is reduced/destroyed
- Errors are caught on your computer not the server - most of the time
- Your script is multi-platform - both the script and the new line characters
- Only one file instead of thousands (exageration of includes)
Just make sure that the backend is uncompressed and the shebang line of your
file is correct, on the file, for the server before shrouding! This is all
presuming you're using a remote server. You could bind it then it would be more
powerful - ie it could accept files by the command line from the server to parse
- I think i've gone off the point!
Alex
4. Re: 2.4 versus 2.5 as CGI
Alex Chamberlain wrote:
>
> - ie it could accept files by the command line from the server to parse - I
> think i've gone off the point!
Not at all! Very interesting for maintenance tasks of web sites.
Thank you for your time (Alex and Vincent)
