Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Fastest Web Language On The 'Net?

Cliff posted more than 13 years ago | from the and-they're-off dept.

Programming 265

TheCorporal asks: "Our company has come to the point in our development where we feel it is time for a recode. We are rewriting code for a large multiplayer, browser/text, turn based strategy game (Like Utopia), and would like to know the best language solution in terms of speed. A Rapid development platform would be nice, but most important is the speed of execution." There's more below, but the question is simple, which language is the swift hare of the net, and which one is the toiling tortoise, and where do the others fall, in between.

"Basically, we are not experts in any one language, but have quite a bit C/C++/Perl experience. The target platform will be Apache on *nix, but a portable solution would be good. At the moment we have the engine coded in C for CGI which then interfaces with MySQL to store game data. We are thinking of hacking in FastCGI support for a good boost in speed, but we feel a complete recode will be neccesary, as the amount of players in the game will soon be hitting 5 figures."

"At this point we pretty much know CGI alone is out of the question from a speed standpoint, so we are looking for something a bit more robust. We have heard that mod_perl may be a good solution, but have also heard the same for Python, PHP, C++, etc, so if anyone has experience with dynamic content like this, and has some suggestions and comments as to the merits of your choice, we would appreciate it."

Meanwhile, on the other side of the galaxy, slartiblartfast asks of his improbability computator, a similar question: "I have been wondering for a while if anyone has some really good metrics on the relative performance capabilities of the different scripting languages. By scripting languages I mean Perl, PHP, JSP, ColdFusion, ASP etc and by performance I mean how many pages can each one serve per second for the same hardware and load test? Every benchmark I have seen was commissioned by the creators of the technology that eventually won the test. i.e. The guys implementing the technology that won just happened to be on the core development team for the product. Now I just can't swallow that sort of thing, so I thought I'd ask here. Has a truly independent test been done that didn't favour one technology over another, or that at least invited the best from each area to build and optimize the site to be tested?"

Careful. There are lies, damned lies, statistics...and then there's benchmarks. It's a quote that's been seen often enough, here on Slashdot, but it still has its own bit of wisdom to impart.

Sorry! There are no comments related to the filter you selected.

php (1)

Anonymous Coward | more than 13 years ago | (#361142)

FWIW, PHP seems to be the most stable all around. I don't know about 10000+ users, but it does well on just about everything else

XUL (1)

Anonymous Coward | more than 13 years ago | (#361143)

Hell, you could submit it as a lacking feature in Mozilla, and if you're lucky they'll code it in _for_you_ in their .9 milestone.

PHP (1)

Anonymous Coward | more than 13 years ago | (#361144)

PHP runs circles around other languages, especially when you download the ZendOptimizer (a free download from We host a site that gets in the neighborhood of 10 Million hits a month, with just about every page on the site hitting the MySQL backend with large amounts of data and it runs as fast as if you were the only one browsing the site.

Re:PHP (1)

Wastl (809) | more than 13 years ago | (#361145)

This may be true when using the application for just delivering content from a database or something similar that doesn't require to process data over several connections.

On the other hand, complex web applications need a sophisticated session management and the program should not be called anew on every connection. True, PHP provides some session management, but Java Servlets tend to be much faster in such cases.


Java Servlet or Apache Module (1)

Wastl (809) | more than 13 years ago | (#361146)

If the application has to serve dynamic content to a browser, I would recommend to use Java Servlets. This may appear to be a slow solution on first look (Java is 10-20 times slower than C in most cases), but there are some considerable advantages to this approach:

  • Java Servlets run over sessions: With standard CGIs, the program is called again and again on every connect and you thus have to deal with data exchange via slow means (i.e. files on the hard disk etc). Even when using FastCGI, you will have independent processes (but I am not familiar enough with FastCGI). With Java Servlets on the other hand, you have a shared data space, each connection is handled from a pool of threads and has access to the same data. Processes need not be started again, it's just calling a method when a connection is made.
  • Scalability. With Java Servlets you can easily have a cluster of Apache webservers and Java Servlet engines without changing the code
  • Rapid Application Development. Java Servlets are usually much faster to implement than equivalents in C or Perl. You have session management, threads, and many API functions built-in

There is also a way to achieve this in C: Write an Apache module. This will almost certainly provide the maximum speed. However, the development effort will also be considerably higher.


Perl? (1)

mholve (1101) | more than 13 years ago | (#361148)

If you're into Perl, check out Velocigen - it's like mod_perl, but a much, much better/faster design. Depends on if you want a free solution, or a commercial one and how fast you want to go. [] Everything Solaris [] will be doing a "shoot out" between Apache w/mod_perl and Zeus w/Velocigen, among others like iPlanet and Roxen shortly.

Re:C or C++ Is probobly your best bet (1)

TooOldForThis (2437) | more than 13 years ago | (#361149)

Java servlets will beat c/c++/perl/[name your favorite language or scripting environment] in nearly all cases. The exceptions will be isapi/nsapi/apache modules written directly to the webserver api. The other benefit is the fact that you have access to the full java api, which provides extremely rich functionality - anything from sending email to building images on the fly is quite easily implemented.

Re:Good design is fastest (1)

mo (2873) | more than 13 years ago | (#361151)

One other addition.
PHP, JSP, or any other language that you can embed into your web server would be fine. Although I wouldn't use anything other than mod_perl or C apache modules, as long as you aren't forking your CGI as a separate process you should be fine.

Re:Consider removing Apache (1)

PCM2 (4486) | more than 13 years ago | (#361154)

Fair enough, but this is one reason Apache was designed with an API and is released Open Source.

Investigate mod_perl, etc., before casting aside Apache.


Re:JSP + Servlet + EJB = Heaven (1)

Mad Browser (11442) | more than 13 years ago | (#361159)

<A HREF="">JBoss</A> is an excellent Open Source EJB server, plus all the other J2EE goodies. Some say better than WebLogic.

Re:JSP + Servlet + EJB = Heaven (1)

lostguy (35444) | more than 13 years ago | (#361177)

php, optimized with zend's optimizer will outperform jsp by about 15%

Be careful with that kind of generalization, unless you're going to post references. There's a huge variation in jsp engine performance. This [] is a vendor benchmark site (so take it with a grain of salt, especially where their product is concerned), but you can see how wide the range of performance can be between JSP/Servlet engines.

Use what you know. (1)

Ekman (60679) | more than 13 years ago | (#361185)

The speed differences between various languages is not so important as the speed differences between various technologies. CGI for example is going to be slower in any language and on any web server, than using some sort of in-process API.

Choose a fast web server that allows you to embed scripts inside the server process. Apache gives you lots of choices in this area: mod_perl, mod_python (and mod_snake), PHP or even C. But Apache isn't exactly the fastest web server on the face of the earth (but it should be fast enough). AOLServer is very fast and lets you use Tcl or C (PHP works too, I believe).

The point is that you should use the language you're familiar with and spend more time worrying about the environment the software will execute in. That's where you're going to get the most performance improvements.

What are you... (1)

iiiFEAR!!! (65743) | more than 13 years ago | (#361188)

a retard? C is hands-down the fastest mostly-cross-platform language on the block. What CS school did you go to?

Some information on Python (1)

eAndroid (71215) | more than 13 years ago | (#361192)

Python on its own is not a speed demon by any means. What it is fast at is development. And it is extremely fast.

I've found that whenever I need my Python to go faster coding up a simple C module for python is as fast as I'll ever need. I've gotten a 100x speed improvement by writing a simple text manipulation function in C.

However, more to the point of your web-based interface question, I don't think that language selection will really have much bearing on your actualy real world performance. I mean, look at Slashdot! It is written in Perl and not even the most optimised perl, and yet they are handling extremely large amounts of traffic.

I'd let slashdot be your model and use what they use: hardware. While perl is faster than Python the development time you save should let you afford more hardware if you need it. But I don't think you'll need it.

PHP and the Zend engine (1)

JDizzy (85499) | more than 13 years ago | (#361195)

PHP is what I use strickly because it was designed from the ground up to work on the web, and to be extreamly fast. The Zend engine, for those that dont' know, it's the component that watches the behavior of the php scripts and then optimises the apache server accordingly. I liken the functionality to the code-morphing tech in the Transmeta chips in that Zend looks for more efficient ways to run your scripts. This is unlike other technologies such as mod_perl, for example, that dont' use any realtime optimization. I cannot comment on CFM, JSP, or ASP cuz I dont' know enough about them, but I do know that most folks say PHP is faster than them, but again it might be the jaded remarks of PHP enthusist. I think that C/C++ would be fast, but please, its not a fast process to develop in, and will take more time than a scripting language to implement. If you think c/c++ will take a long to to implement, the Assembally with take twice as long. These compiled solutions are not RAD (rapid application development). Unfourtunatly I hear ASP is good for RAD, but do you really want to support a proprietary system that doesn't work so good on Unix w/Apache?

Re:JSP + Servlet + EJB = Heaven (1)

Serpent Mage (95312) | more than 13 years ago | (#361202)

And using them will make you want to go gcj@#$!@#

Talk about a nightmarish java compiler.

Re:Servlets are pretty good, I would question MySQ (1)

Master Bait (115103) | more than 13 years ago | (#361209)

I agreee. It's better to buy a faster PC CPU -- if they're at that level. That's because it's better to go home at 5 than it is to go home at 7:30.


Wait a minute, compiled is fine in more situations (1)

moogla (118134) | more than 13 years ago | (#361210)

Generally, you don't write compiled CGI that gets rolled into the server. You can get significantly better speed and use of memory, but this is more complex than it's worth. Using compiled CGI, you do not need to restart the server when you recompile something.

In fact, you can emulate a lot of the features of stuff compiled into a module by using very small compiled CGI that do very little, and pass off the work to server processes/SQL/whatever. By avoiding linking to libraries you can avoid, and reducing code/memory size you reduce overhead. Also, try having only a few executables with lots of features, and hardlinks to them with different names for different purposes (think shell commands for root floppy disks, where cat, ls, and more are all the same proggy)

On a completely unrelated note, I've had good experience using Makefiles to keep the state of the CGI scripts up to date when making modifications, if that is another concern.

Use C. Or C with C++ wrappers. (1)

moogla (118134) | more than 13 years ago | (#361211)

I have had great experience with using C and C libraries for developing websites. They are incredibly fast. To reduce overhead, consider using FastCGI (it's really cool too, but I haven't tried using it. I only know what it can do from other people where I work). Or you can do what I do, and make your cgi apps REALLY small (&lt100K) so they don't ever leave memory when they get called. And make them handle only the work associated with formatting/displaying the HTML and relaying requests: put all the heavy processing in backend server and communicate via sockets or better yet, IPC shared memory.

Re:Answer + Pool (1)

Verloc (119412) | more than 13 years ago | (#361212)

I really can't help myself. It's POLL, not POOL. Sorry

Re:Speed is relative (1)

Darlok (131116) | more than 13 years ago | (#361217)

... and my apologies. My brain somehow dumped the fact that you were using MySQL.

But still, the question is valid. MySQL has all sorts of different performance modes depending on the table type you use and the numer of connections you form to it. If you only have one connection passed around to all of your script executions, that's one thing. If you have a new connection for each script execution, that's another.

The particular language you use won't really save you there. Anyhow... My $0.02.

Custom HTTP server (1)

SClitheroe (132403) | more than 13 years ago | (#361218)

Basically, it sounds like you need a dedicated game server, not an HTTP server tied into a game backend.

I'd create a custom HTTP server, that has the game logic built right in. Thanks to open source, getting a fast efficient HTTP handling mechanism is easy (strip down Apache, or look at some other, smaller open source servers). Then just add your game logic, either as statically linked code, or even better, as loadable modules of C or C++ code. You get the best of all worlds; HTTP support, blinding speed (no CGI interface overhead, no JVM, no script interpreters, etc), all in a tightly integrated package.

Re:JSP + Servlet + EJB = Heaven (1)

avandesande (143899) | more than 13 years ago | (#361228)

Are you using this with swing or awt? cgi stuff would not use any of these classes and i suspect/hope that using it with text only stuff would be less buggy.

Perl/C/C++ (1)

Darkness Productions (143908) | more than 13 years ago | (#361229)

C/C++ would probably be the best for overall speed, just because it is fully compiled and could run like lightning, provided that there weren't any memory leaks or the like. Perl would also be a good choice, just because of it's extremely large abilities. ASP/ColdFusion/PerlScript is always bad because they are so damned slow. We use ASP at work, but I would much rather use Perl/PHP to do the same thing.

Re:XUL (1)

f5426 (144654) | more than 13 years ago | (#361230)

Rotfl. Best one so far. Not sure he'll get the perf he needs, but there is no silver bullet.

Re:Consider removing Apache (1)

ganjuror (150727) | more than 13 years ago | (#361232)

uh... Isn't that what Apache MODULES (ie: php, mod_perl, etc) are for? How much more can you truly optomise a server than embedding the processing of scripts IN apache? Would it be possible to take the Apache source, and dumb it down to cut all overhead but the processing of a specific module, run it as a seperate server, and get the same effect?

note: I'm hardly a 31337 h8x0r, so I may well be missing something... I'm only asking that the more 31337 enlighten me, and anyone else who may be reading ;)

Re:Do it in Assembly (1)

Saint Aardvark (159009) | more than 13 years ago | (#361239)

Let this be a lesson to you...preview, preview, preview.

Re:Do it in Assembly (1)

Psiolent (160884) | more than 13 years ago | (#361240)

Better yet, design your own microprocessor for the game and write the entire thing in microcode.


You have got to be a troll (1)

codepunk (167897) | more than 13 years ago | (#361244)

Java crap is slow as hell just hit any jsp site to see how bad. even poorly written perl or python could hands down smoke jsp. Hell I bet even cold fusion can beat that junk

Re:Do it in Assembly (1)

FortKnox (169099) | more than 13 years ago | (#361245)

I think he'd be better off with a colorful combo of :
  • Fourth
  • Ada
  • Prolog
  • And LISP


Perl and PHP are da sheit! (1)

WhyPanic (191016) | more than 13 years ago | (#361253)

JSP is inherently slow, and taxing on a system (read you need an expensive system). ASP on Linux, I am very wary about because most people automatically associate ASP with M$ IIS/SQL Server. Perl has good speed on any system, and it is easily integrated into an Apache MySQL system. Then again if you are doing Apache/MySQL why not PHP?

True Server-side speed (1)

bziman (223162) | more than 13 years ago | (#361264)

For server-side scripting results that blow Java, Perl, and C out of the water, your best bet is to go with the MS QBasic interpreter. If you're set on compiled code as the way to go, you'll have to settle for COBOL.

Sorry, I just hate these "my language is better than your language" arguments. Anything can be coded for speed and anything can be coded to suck.

It's not Perl that makes Perl based sites suck -- it's the fact that CGI scripts spawn a new process every time they are called. More advanced server side scripting languages use a single process to handle requests. I'd personally like to see a Perl CGI gateway that doesn't have to spawn a new interpreter everytime.

Frankly, I think ASM will have the same problems that you'd see with Perl -- the overhead is not execution of the script, it's the initial setup time for each request.

Remember, if high performance was just a matter of switching to a faster language, we'd all be using that faster language. Usually it's something else that makes it fast or slow.


Re:C or C++ Is probobly your best bet (1)

NonSequor (230139) | more than 13 years ago | (#361269)

If you really need to you can always use inline assembly with C or C++.

"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)

Perl, Zeus and Velocigen (1)

Elgon (234306) | more than 13 years ago | (#361271)

Zeus with velocigen is far, far faster than apache with mod_perl I believe: Unfortunately Zeus ain't free but it is a complete piece of piss to use, is secure and is the fastest webserver there is, by quite a long way.


Re:Don't do it in Java (1)

byronbussey (238252) | more than 13 years ago | (#361273)

it is the slowest

You're asking the wring question. (1)

PhipleTroenix (240551) | more than 13 years ago | (#361277)

I think we all know that assembly is the fastest. Unfortunately that is probably not the answer you were looking for, so you must have gotten the question wrong. Either that or you're just a troll.

Re:JSP + Servlet + EJB = Heaven (1)

HaiLHaiL (250648) | more than 13 years ago | (#361280)

By adding "EJB" to the mix, you're limiting them to paid software (unless someone can tell me about an Open Source EJB container?). As far as Servlet environments go, if you're looking for speed, make sure you use Apache/JServ, not Jakarta Tomcat. Tomcat supports newer specs, but JServ is a tried and true fast servlet environment. Despite Java's general sluggishness, on good hardware it will get the job done.

php can handle high loads if optimized. (1)

Anomymous Coward (303315) | more than 13 years ago | (#361287)

what i can suggest, from playing around with multiple languages (jsp, perl, python, php) on FreeBSD/apache, is to use php [] optimized with zend's optimizer [] .... the speed boost is about 15%, and if apache is configured correctly, or even patched for speed, php will outperform any other similarly prepared language.


Re:Servlets are pretty good, I would question MySQ (1)

3am (314579) | more than 13 years ago | (#361293)

i was going to suggest postgre - i agree that mysql isn't really mature as far as dbms go.

Well, for benchmarks..... (1)

nate1138 (325593) | more than 13 years ago | (#361299)

Check out This page [] for some benchmarks on web languages. The results are not what you'd expect from a perl page...

C or C++ Is probobly your best bet (1)

benii (325722) | more than 13 years ago | (#361300)

I would reccoment doing it in C or C++ because they're both fast and much easier to maintain than assembly. (which will always be faster) Some other languages would be easier to program in but if you just looking for speed go with C/C++.

Be carefull with statistics.... (1)

famazza (398147) | more than 13 years ago | (#361301)

A regular fireman has a building in flames, then he called the super-math-man...
The super-math-man did his math things and told the fireman that he would need exactly 1569 liters of water to stop the flames.

Then he called the Cmdr-physics...
The Cmdr-physics did his physics and math things and told the fireman that he wolud need aproxim. 1600 liters of water to stop flames.

Then he called the Captain-enginneer...
The Captain-engineer took a flight all over the place and told the fireman that 8000 liter will be enough.

Then he called the All-mighty-statistic...
The All-mighty-statistic asked him: "How much Water do you want to spend?"

So, be carefull with statistics. And keep using C/C++!

C or C++ (2)

Alex Belits (437) | more than 13 years ago | (#361306)

As a module, of course -- either Apache (native or through or fastcgi) or my fhttpd (that I wrote with protocol that looks a bit similar to fastcgi, but allows more complex processing models).

Bash! (2)

Nate Fox (1271) | more than 13 years ago | (#361307)

May I suggest using a shell interpreter of some type? I like bash, but csh may be your calling since you guys have some C/C++ background. Forget the PHP/Perl/Python thing. Just use the URL and/or cookies to store variables! No need for a database, either! I say make the client do all the work. :-D

If Bill Gates had a nickel for every time Windows crashed...

Re:Not ColdFusion or ASP (2)

sheldon (2322) | more than 13 years ago | (#361309)

Out of curiousity, were you trying to write monolithic applications using thousands of line of VBScript within ASP?

Or were you doing the intelligent thing, writing all your logic into compiled VB/VC components configured within MTS and then called by a few dozen lines of ASP code?

There's more to it than that, but...

Can you say DUH?

Re:JSP + Servlet + EJB = Heaven (2)

acroyear (5882) | more than 13 years ago | (#361314) [] is an opensource EJB2.0 container.

Re:JSP + Servlet + EJB = Heaven (2)

Mad Browser (11442) | more than 13 years ago | (#361318)

The link: JBoss [] .


Re:C or C++ (2)

The Dev (19322) | more than 13 years ago | (#361320)

You might be surprised how fast and how little memory a C language CGI runs. Of course if
you are doing lots of DB queries each instance, you would benefit from a persistant app.

Re:Well Duh (2)

SheldonYoung (25077) | more than 13 years ago | (#361321)

Even assuming developers can even agree what a "reasonably intelligent" program is, I don't think most applications are reasonably intelligent, if for no other reason than design goals change.

For example, what they have right now may have been a great design if it was intended for a small audience. Small, simple and fast. But if the goal shifts, all of the sudden the current design is no longer right, even though it's still "reasonably intelligent".

Even assuming two similar designs, the language doesn't make that big of a difference. Even going from the slowest to the fastest is only a factor of two or three. And if it's only a factor of two or three generally the effort is better spend on hardware, which speeds up everything and not just one application.

We live in an age of where orders of magnitude growth is common. This will change, but until then we have to plan for incredible growth and a simple language change alone isn't going to cut it.

Re:Language choice (2)

SheldonYoung (25077) | more than 13 years ago | (#361322)

To make up for my transgression, and horrible editing in my post, I'll add my few:

* We're running a site with a few million hits per day, and we're considering switching from Apache to IIS because we heard it was faster. Thoughts?

* Should be move from BSD to Linux because we can by CDs at our local drug store?

* Bruce Perens or Natalie Portman?

* What's the better breakfast cereal: Hot grits or Glorious MEEEPT?

Re:JSP + Servlet + EJB = Heaven (2)

lostguy (35444) | more than 13 years ago | (#361325)

JSP's are pretty robust, but slower than pure servlets (which are also robust)


JSPs are compiled into servlets. Admittedly, they may be slower than intentionally-coded servlets, but after the first call, they are servlets.

But they don't have to develop, only port. (2)

Ungrounded Lightning (62228) | more than 13 years ago | (#361332)

So if everyone really knows what they're doing (cross fingers), go with Perl, because you cannot get that much expressiveness in any other language. If you think your development skills would benefit from additional structure, go with C++.

Generally good advice. But this is a special case.

The questioner already has working code, and wants to recode it in another language to speed it up and perhaps "iron" it into cleaner form for future enhancements.

In such a situation you can inherit much of the organization and concentrate on speed. Porting to a language that's enough different than the original to bring your attention to things as you port (rather than making a mechanical translation) but not so different that you have to totally reorganize or implement a LOT of of replacements for language builtins will probably give you the cleanest result. Or if you're already in the likely fastest target language, sit back and look over the existing organization to see what can be improved.

C/C++ tends to be the fastest in those enviornments where it's appropriate, and IF you can find the right stuff in the standard libraries/class libraries you probably won't have to implement a lot of replacements. Let's assume for the moment it would be a good choice. Since this is a port for speed, it would be a good time to come to a real understanding of the underpinnings of the language, so you can squeeze the most out of it.

But before you dig in, try instrumenting the existing system and find out where its bottlenecks are. You may find the real problem isn't the language, but some other aspect (like API delays or database time). If that's where your time consumption or latencies are, you'll have to fix or replace them to get your improvement anyhow. If the bottlenecks aren't inherent in the existing language (neither the language itself or its API requirements), you might find you can fix them and leave the bulk of the code just as it is.

Re:Do it in Assembly (2)

lizrd (69275) | more than 13 years ago | (#361333)

Were you lucky enough that when you were finished you got to dump it to one of those comically large 8" floppy disks? Or did you have to output your results to paper tape?

mod_perl mod_php (2)

Serpent Mage (95312) | more than 13 years ago | (#361337)

mod_perl and mod_php are most likely going to be your optimal solutions. They are very well optimized for large performances and the retain the code in memory for faster execution. In terms of perl, mod_perl is MUCH faster then FastCGI but there is a larger memory requirement. mod_php is IMHO the better way of going but then again, mod_php is only available on the unix platforms which defeat your cross-platform desires (I'm not sure if mod_perl is on win32 boxes or not). PHP alone is not capable of handling the demands that you are talking about but because of the way that mod_php caches and retains in memory the php scripts it is also a faster solution and you are having to make less requests to the harddrive which cause the minimal but neccessary speed increases. However, your overall best bet is to do some kind of content distributing and pushing the contents closer to the users regionally and/or server clustering is probably a must.

zend costs (2)

siculars (103175) | more than 13 years ago | (#361338)

dont forget that zend costs in a commercial environment. that is where the speed lies with php. i would say write the whole thing in c and set it up as an apache mod. a good book is 'writing apache modules in perl and c', stein & maceachern, published by o'reilly. good luck.

Machine code or nothing! (2)

swordgeek (112599) | more than 13 years ago | (#361340)

OK, maybe an exaggeration. Programming in straight machine code will give you the fastest and tightest code...when you finish in 2007!

C is probably the best compromise, but design is crucial--go read "Mastering Algorithms with Perl" or something similar to remind you how important GOOD coding for the situation is, rather than concentrating on the language.

eweek recently put php on top (2)

avi33 (116048) | more than 13 years ago | (#361342)

In the last 6 months or so, eweek had a shootout between scripting languages...php spit out 61 pages per second, i believe, putting it on top in the speed category, above asp and jsp. can't seem to find the article on their site tho...

Not just language... it's all in implementation (2)

Oroborus (131587) | more than 13 years ago | (#361343)

More matters than just language. If you were running on an NT/2000 machine you would be best off using either ASP/COM or ASP.Net. (crippleware anyone?) But being on a *nix platform, you would probably be best off going with a Java servlet solution.
Java and the J2EE not inherently any faster than any other technology, but has a huge advantage because of vendor support. Everyone's scrambling over eachother to provide the best and fastest implementation of the J2EE platform, and the results are trickling down to free servers.
A good example would be the Orion J2EE server, which if benchmarks are to be believed is far and away the fastest solution. Find it at: []
I use it myself, and can vouch for ease of use and speed, though I haven't done any benchmarking.
Check out some amazing benchmarking figures for it at: ml []

make it a module (2)

aminorex (141494) | more than 13 years ago | (#361349)

the speed solution is not to recode as a script, but to move the app from cgi to a loadable module.

Real comparison (2)

avandesande (143899) | more than 13 years ago | (#361350)

Here is a link to a pdf [] that has real performance comparisons between scripting languages and c/c++. It has productivity figures as well.

Re:Esperanto! (2)

seanmeister (156224) | more than 13 years ago | (#361352)

<i>[Man, what a bitch it would be to try to code in Magyar...]</i>
Man, at first you said "Marglar" - now THAT would be a bitch!!<P>
$marglar = "Marglar!";<BR>
marglar "Hello there. What is your marglar?\n";<BR>
$you = <STDMARGLAR>;<BR>
marglar "Hello, $you. Marglar to $marglar.\n";<BR>
</TT><P>(Slightly obscure South Park reference...)

Use The Source (2)

codepunk (167897) | more than 13 years ago | (#361355)

Compile it into apache if you want to break speed records. Create a apache module to run your stuff and compile it right in. It is not goig to run any faster than that.

Re:C or C++ Is probobly your best bet (2)

grammar nazi (197303) | more than 13 years ago | (#361357)

Why stop there?

Assembler CGI scripts IMO are the fastest most efficient web scripts that you can write.

You can write them because I wouldn't want to write Assembler CGI scripts, but they would be efficient.

PHP/Zend is free! (2)

mgkimsal2 (200677) | more than 13 years ago | (#361358)

What do you mean zend costs in a commercial environment? The underlying zend engine used by PHP is free! The zend cache product costs money, but is definitely not needed by PHP, and there are free open source alternatives to boot. PHP/Zend is most definitely free in commercial settings. We've got loads of them running, and didn't need to pay a dime in licensing fees.

Go with experience (2)

JWhitlock (201845) | more than 13 years ago | (#361359)

The fastest language in execution speed will probably be the one your programmers are most familiar with. C or Assembly would be the fastest when optimized, but it is also possible to code a really slow implementation. If your programmers start with a language they are familiar with, then learn a bit about optimizing that language, then they should do alright.

Having said that, it sounds like several languages would support your application, and different ones would be best implemented in different languages. A glue language with calling ability to other languages (C, C++) may be good for the central parts, and farm database work out to a database language (MySQL). This way, you can take advantage of speed gains in either domain (C++ speed optimizations for low-level execution, MySQL for quantum database improvements).

This will also force you to think about the design a little more, as well as the interfaces. With good interfaces, the implementation can thrash around a bit, but everyone can still be doing their work, and you can prototype a lot faster.

Of course, I haven't experienced your situation. Why don't you write the developers at Utopia, see what they use, and if they would change anything about their language of choice?

Ok.. (2)

PHr0D (212586) | more than 13 years ago | (#361360)

Lets not forget about fortran! [] .. Oh, you said for the web.. right.. *cough*.. Oh look, here comes my bus..


Re:C or C++ Is probobly your best bet (2)

BlowCat (216402) | more than 13 years ago | (#361361)

It's a common misconception that Assembler is faster than C. Good compilers know how to group instructions together so that they execute faster on the given processor. It's quite hard to do by hand.

Compilers are not so dumb as in the times of 8088, and the processors are not so simple anymore.

Re:Do it in Assembly (2)

3am (314579) | more than 13 years ago | (#361364)

hell, do it in 0's and 1's....


most software shops can't realistically develope in assembly. it's simply to difficult to trace bugs in the code, and there are too many ways for bad developers to shoot themselves in the foot. odds are that the percentage gain they'd get in performance from coding in assembly would be offset by the time/cost of writing the software.

Whatever it's written in, good design is most important anyway.

All being said and done, it sounds like you should write it in c++ with an optimized compiler for the best performance, although java servlets or a java server would be the easiest to write, and quicker to develop without losing too much performance.

Re:JSP + Servlet + EJB = Heaven (2)

CrackElf (318113) | more than 13 years ago | (#361365)

Errr, I have been coding in java for the last 2.5 yrs, and I have to say, java has some advantages, but it has some pretty serious drawbacks as well:
anytime use java, you loose speed. JSP's are pretty robust, but slower than pure servlets (which are also robust), applets (over the net) tend to be slow, because it takes an age and then some to download a medium sized applet, and EJB's (the last time I used them) were less than reliable.
the advantages of the design, implementation, deployment, and reusability / consistency are all valid.

Re:Do it in Assembly (2)

---s3V3n--- (398159) | more than 13 years ago | (#361367)

As of win32 I thought C++ was just as fast as Assembly.

Re:Do it in Assembly (3)

PCM2 (4486) | more than 13 years ago | (#361370)

I concur. But you should point out that developer efficiency is a good thing as well. For rapid application development, he should seriously consider using a wire-wrap kit, rather than etching the circuit boards himself.

Re:Do it in Assembly (3)

ewhac (5844) | more than 13 years ago | (#361371)

Assembly? Geez, kids these days. Back in my day, we entered machine code directly, entered in octal by toggling address and data switches on the front panel and hitting DEPOSIT NEXT.

(Better mod this down; "Can You Top This?" cascades can get out of hand...)
(And no, I'm not kidding, I really did fiddle with IMSAI and Altair boxes...)

Some data points (3)

Lumpish Scholar (17107) | more than 13 years ago | (#361372)


"An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl" []

Kernighan and Pike's The Practice of Programming [] (reviewed here [] ), especially chapter 7 on performance

This comparison [] (just popped up from a Google search).

Obvious advice: Measure your current system, find out where it's really spending it's time.

If programmer productivity is irrelevant, you'll be hard pressed to beat well-written C. (And if wishes were horses, beggars would fly.-)

Re:JSP + Servlet + EJB = Heaven (3)

jilles (20976) | more than 13 years ago | (#361373)

And the people who do realize don't realize they are not addressing any performance bottlenecks by using it. Get over it, native compilation does not solve many Java performance problems. There's a reason for native compilers such as towerJ and gcj not being used that often: the performance gain is not that big and sometimes not even there!

PHP (3)

austad (22163) | more than 13 years ago | (#361374)

PHP is fast and runs on just about any platform. With the use of the ADODB abstraction layer, you can easily switch databases if needed instead of changing a ton of code. It has built in session management, but you can easily store your session data in your database, then you can just add identical servers as your load goes up, and you don't have to worry about connection persistence across servers, so it's extremely scalable.

If you add the Zend optimization engine, it's even faster if you're doing alot of loops and such.

Moto (3)

hugg (22953) | more than 13 years ago | (#361375)

There's a language called Moto [] that compiles directly into Apache C modules. If you cache your database calls properly, you can get supposedly get 1000's of hits per second. Probably not for everybody, but if you need extreme speed... you need it!

Algorithm Design is the Barrier, not Language (3)

Ted V (67691) | more than 13 years ago | (#361377)

Having spent 10 years developing software, let me assure you that your greatest speed gains come from the algorithm design, not the language used.

The best example I have is from 2 years ago when I worked for Motorola. I wrote a simulator that performed a large file with a real device on the other side. The simulator was also responisible for multithreading other tasks from the real device at the same time (although the program only used one unix thread to do this). We wrote our simulator in Perl [] and the actual device ran compiled C code.
It turned out that our interpretted Perl code sent packets to the C program so fast that the hardware running the C code crashed. We literally had to cripple our Perl code so it sent the data at a slower rate.

That said, I firmly believe that it's far more important to choose a language that best suits your development abilities and choose language speed second. C++ and Java are great languages if you want to be forced into object oriented development, and sometimes that's what you need. Personally I love perl, but learning how to write clean perl code is extremely difficult (though rewarding).

So if everyone really knows what they're doing (cross fingers), go with Perl, because you cannot get that much expressiveness in any other language. If you think your development skills would benefit from additional structure, go with C++.


PHP4/Postgres (really!) is your best bet (3)

stuce (81089) | more than 13 years ago | (#361378)

There was an article [] here on slashdot that compared four different scripting languages. From the standpoint of speed PHP came in first. PHP has a reputation of being the fastest web scripting language and, to be honest, is a joy to program in as well. If this is not enough speed Zend [] sells a PHP cache that will precompile all your pages to speed things up even more. I believe there is a free version of the PHP cache out there but I don't know it by name.

And before you use MySQL please read this [] . MySQL has a reputation of being the fastest open source database but it really can't scale like Postgres can.

Servlets are pretty good, I would question MySQL (3)

smoondog (85133) | more than 13 years ago | (#361379)

If your tables are *huge* MySQL may not be
the best solution, not sure on performance
but it is something to check. Your language
is not the only thing you need to consider. You should also consider the DB engine and the server platform. Why recode when you can purchase more hardware? :) Might be cheaper.

Servlets are quick, well supported and popular.


More to Speed than Language (3)

cs668 (89484) | more than 13 years ago | (#361381)

People say java is slow. I can write really fast Java code :-)

It really depends on how well you know the language and environment you are working with. If you pick up java and go to town it might be slow, same with perl, or C. As an example you are trying to change your C execution environment by using FastCGI. Has nothing to do with the language C but, the way that the client comunicates with that C code.

You need to come up with a good plan from front to back and then pick the language or languages that will make it happen.

Not ColdFusion or ASP (3)

tokengeekgrrl (105602) | more than 13 years ago | (#361382)

I have worked with both of them and they are both resource hogs. They work fine if your traffic is somewhat limited but neither scale very well from my experience.

And I would definitely consider upgrading the database to something more robust than MySQL.

- tokengeekgrrl

Speed is relative (3)

Darlok (131116) | more than 13 years ago | (#361383)

The question you're asking about what is the fastest CGI language is sort of a loaded one. Different languages excel at different things. Will you be accessing a relational database (which one?), will there be only one server or will it be load-balanced over several, etc etc etc? Heaven forbid you're storing something of this magnitude in on-disk flat files, but if you are, well, that needs to be considered too.

PERL is multipurpose, but won't win many road races for much of anything. PHP has ease of use, but its database support (even with pconnect) and performance in general is not the quickest unless you're hacking the Zend optimizer by hand. Python is getting closer, but it's still not the fastest. ASP isn't either.

You're identifying the right problem, but IMHO, asking the question wrong. I'd identify and measure the speed of your underlying technology first. Depending on what you're doing, the script may not even be the bottleneck! (Though it's hard to say with the amount of info provided.)

Either way, good luck!

Answer + Pool (3)

f5426 (144654) | more than 13 years ago | (#361386)

Put it in the kernel. Writing it in assembly would be a plus too.

Okay, this is a stupid answer, but the question was stupid already:

> we feel it is time for a recode

The pool:

"Everything is running like crap. You've got a cold feeling". What is it?
* time for a recode ?
* time for an ask slashdot ?
* time for an upgrade ?
* time to check that the 'turbo' button is pressed ?
* time for hiring good engineers ?
* time for a profiling session [<- hint] ?
* CowboyNeal ?



Re:Do it in Assembly (3)

Saint Aardvark (159009) | more than 13 years ago | (#361387)

Machine code? Geez, you wanna go part-time on us, you just say the word...

I hand-filed gears, sprockets, cogs and pistons for my own Babbage Difference Engine, arranged for shipping for thirteen metric tonnes of high-grade coal from China, and blew my own glass cooling jackets from Nova Scotia beach sand. The result is the fastest goddamned shopping cart program on the net.

Well Duh (3)

vodoolady (234335) | more than 13 years ago | (#361389)

And you should also try to write your software with fewer bugs. And if you're in a boxing match, try to land more punches than the other guy.

Seriously, what kind of advice is 'use good design'? I've heard so many people spout this pretty obvious goal as wisdom, and then go on to point out that stupid solutions run slowly now matter what language you use. Given two reasonably intelligent programs, the choice of language makes a huge difference in the speed of an application.

the quickest solution (3)

mongooze (316829) | more than 13 years ago | (#361390)

while cgi is fine and dandy, the absolute quickest solution would be to generate a collection of static html pages for every possible combination of variables... granted this could take some time ;)

Do it in Assembly (4)

SpanishInquisition (127269) | more than 13 years ago | (#361392)

it is the fastest

Go Compiled (4)

Natak (199859) | more than 13 years ago | (#361393)

Well if you want top speed you can only get that from a compiled development platform. Most web environments have grown up as an interpreted solution in order to make changes easier (good old internet time). So if you care most about speed you want to look at a couple options, first is creating your own ISAPI if you're looking at NT, or your own DSO if your looking at apache. You can code either of these in C, if your also looking at using a traditional database behind the scenes then take a good look at Delphi / Kylix. Delphi creates the fastest web apps while still allowing applications to be developed quickly. There are tradeoffs if you look at a compiled approach. (Like you have to restart the web server if you make a code change). There are many inbetweener type solutions you may want to look at like ASP, or FastCGI.

Have you done profiling? (5)

Anonymous Coward | more than 13 years ago | (#361394)

It's obvious from your post that you have no idea where the bottlenecks are. Before you go making arbitrary changes, do some real profiling of your app. What does gprof say? What does your network testing show? How much time is spent in each component?

Without real tests, your changes are likely to have little or no effect on overall performance.

Texas: all your electricity are belong to us

Good design is fastest (5)

mo (2873) | more than 13 years ago | (#361395)

Although it's nice to speed up your program execution with changes like cgi to fast-cgi, good design will benefit you the most.

What's a good design? Write your code in a way that you can run it on multiple servers with a web redirector in front of it. Try not to depend too much on fancy SQL logic as it is diffucult to scale your databases. Instead, try to stay out of the database as much as possible, and when you do have to use the database, split up your schema such that it wouldn't be that hard to run multiple database servers. Another good thing to keep in mind in MySQL is not to do too complex of queries. MySQL flies with simple selects on indexed fields. Extremely complex updates can really tie up your database.

Now that you understand good design, how do you code your cgi end? For ultimate speed, you could do apache modules written in C, but mod_perl is only trivially slower and much easier to develop. One stipulation is that if you are getting deep into the guts of apache with things like internal redirects or many layered handlers I'd advise using C, but it doesn't look like you'll be doing that.

Re:JSP + Servlet + EJB = Heaven (5)

the red pen (3138) | more than 13 years ago | (#361396)

I'd like to combine this recommendation with the other high-rated recommendation about design.

Many "web languages" are page-centric. PHP, and ASP are like this. Other "web languages" take application languages and tie them to a page-centric mode. Mod-perl does with as does ASP+COM. For a lot applications, this isn't really a problem because the application flow maps nicely to the page flow. When the application does things which can be presented on a web page, but whose behavior is not easily modelled in a page-view manner, then you start to see kludgy implementations.

Java allows you to code in a manner appropriate to the part of the problem you are solving. If you have, for example, a game-play engine that runs in the background, you can easily spawn a Thread for it that will run just like any other Java Thread without any limitations due to being a "web program."

This allows a design where the game engine is nicely abstracted and isolated from the front end. This also makes it easier to have a team of people in charge of making the game cool for users and another team making the gameplay itself cool.

On a side note, EJB's can impose a lot of infrastructure and programming overhead that's unecessary if you don't need the services of a full-blown Component Transaction Monitor. You can frequently do what you want by using regular Java classes or Java RMI.

Consider removing Apache (5)

acroyear (5882) | more than 13 years ago | (#361397)

It all depends on what you're serving. If there's a lot of static pages, or pages in different languages, then Apache is the best mediator involved. This is certainly true of serving unchanging images.

But if everything you do is going through the equiv of "CGI", then forget Apache. HTTP is far too easy a protocol to implement (hell, its the protocol used for lots of "embedded" servers in stuff like Napster and Shoutcast). Implement your own HTTP server where you automatically can have all requests go to an engine for processing directly, and take Apache and all that configuration out of the loop. You'd effectively have two servers running -- an apache server to handle throwing images and static pages around, and a second home-grown server that directly serves up the application data. Doing this won't change that your database engine is your primary bottleneck, but it will reduce all other bottlenecks by quite a bit.

Apache is a general purpose system, and does it pretty damn fast, but for a true special-purpose system, its best to implement your own special-purpose server.

The "embedded server" for Java follows the same principle. Maybe W3C [] has some implementation code in C that may prove useful.

JSP + Servlet + EJB = Heaven (5)

Moe Yerca (14391) | more than 13 years ago | (#361398)

I don't know about speed numbers (everything I've done server side has been extremely fast) but development time is great with JSP/Servlet/EJB. It's easy to build a great OO design, implement it, and deploy it on gobs of web/app servers. It's really a shame Sun is giving Java such a bad name around hard core GNU/Linux peeps. It's such a pretty, robust, fun environment to code in. Try it. You'll like it. Or you'll vomit.

Language choice (5)

SheldonYoung (25077) | more than 13 years ago | (#361399)

In reality, language choice has much less of an impact on the speed of an application than the design. but Even a language that's twice as fast can be ten times as slow with a bad design. Some languages make certain designs easier to express, just pick a language that lets you design the way you want.

The *first* thing you need to do is make the design is right. No matter how fast the language is, the number of new users and new features will outstrip any incremental improvements. Even if you make it three times as fast eventually there will be three times as many users.

The only lasting solution is to design it so it scales. If you don't, you'll be chasing the increasing loads by praying incremental optimization and faster new hardware will keep you ahead of the curve. If you build a successful site, it probably won't.

Consider Slashdot a classic case to study.

Yes compilers are faster. That's why there's RISC (5)

Ungrounded Lightning (62228) | more than 13 years ago | (#361400)

It's a common misconception that Assembler is faster than C. Good compilers know how to group instructions together so that they execute faster on the given processor. It's quite hard to do by hand.

In fact it's research to that effect, a few years ago, that led to the development of RISC machines.

A good assembly programmer could still outdo a compiler when he really focussed. But the compilers knew MOST of the tricks, and applied them consistently everywhere. In competition with assembly programmers - even good ones - the program that had been through the compiler normally came out significantly ahead.

Given this, and the greater portability of things like Unix (which was mostly in C with some minimal assembly where needed), assembly code was mostly dropped except where it was unavoidable (like OS routines to get the stack arranged after an interrupt so you could get back into C).

But given that the compiler was generating essentially all the code anyhow, it made sense to design computers with simplified ("reduced") instruction sets, rather than extended ("complex") sets of feature-prone instructions. Sometimes it would take several RISC instructions to do the work of a CISC instruction. But the compiler could generate it, so it was no skin off the programmer's nose.

With the compiler to do the work, a RISC computer could be very simple internally. This meant it could be very small. That meant the parts could be close together, so it could run faster with a given technology, and that it could be moved to a faster technology sooner, when the production yeild for a BIG chip was still too low but the yeild on a SMALL one was adequate.

The extra instruction fetches were a problem. But instruction cacheing kept the inner loops in the machine, so there was still a big net gain.

Analyze, Design then Code (5)

fayd (143105) | more than 13 years ago | (#361401)

Design is a major issue when talking performance, but there's more to it than that. The poster mentioned using MySQL on the backend. That means there's quite a bit of work to do before we even start mentioning design.

Someone with a fair understanding of data analysis needs to go through and figure out what the data storage needs are. Now pick your database: MySQL is reasonably fast for small databases on small machines. But it reaches its breaking point relatively quickly. My experience indicates that PostGreSQL is the next step up the ladder. With a user base in the 5 figure range, I would run Postgres on it's own machine and watch it closely. If it seems to have problems keeping up (and you're not on too small a machine) you'll have to start looking at a big database (e.g. Oracle).

Also, the other hardware you're running on has some performance implications. Do you have a large amount of physical memory? The more information you can keep in memory, the faster your system. How are your disk file systems layed out (NFS? RAID?). The when you do have to go to the file system, these having resolved these questions will affect performance.

Now we can talk about languages and delivery mechanisms.

You mentioned keeping an eye towards portability. Unfortunately, there are trade offs there as well. If you want speed, portability is your enemy. Java and Perl are great languages (I use them and recommend them often), but they are relatively poor performers. You can pretty much eliminate any interpreted language (e.g. Tcl) and web script (e.g. PHP, ASP, ColdFusion).

The heavy lifters are still C and C++. But even if you write your CGI in C, you're still incurring the CGI penalty (which is very expensive).

If you insist on using Apache, then start by writing an Apache module in C or C++. Even faster than that is to skip Apache altogether and write the entire server yourself. You want this to be web delivered still, which is fine as the HTTP protocol isn't too difficult to implement.

Once you've figured all this out ... NOW you can start your design.

Re:Language choice (5)

f5426 (144654) | more than 13 years ago | (#361402)

You're spoiling the fun. It was the most trollesque askslashdot ever.

They *asked* for a langage war.

Next ones should be something along the line.

* We're a big company porting its stuff to linux. What is the best desktop environment to use ?
* When redoing out corporate backend, we decided to go to unix. But which unix should we choose ?
* Is there any kind of text-mode visual editor on unix ?



Esperanto! (5)

TOTKChief (210168) | more than 13 years ago | (#361404)

Esperanto--the universal language!

Oh, you meant programming language.

[Man, what a bitch it would be to try to code in Magyar...]


Look for the bottleneck first... (5)

tweakt (325224) | more than 13 years ago | (#361405)

Server side script rarely consumes a lot of processor cycles. I beleive the database server and other libraries that you call out to make a much larger impact in speed.

It's all a matter of optimizing the slowest part for the largest gain. Optimizing the script will result in much less improvement than say, switching to a faster database server.

Also next in line would be the web server that is hosting the application. Some scripting languages are possible more efficient than others but that only matters if you're doing a lot of processor intensive things within the script (mathematical calculations, etc) which is rarely the case.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?