Re: [WAY OT] Re: PL/java?

Well,

mod_perl is not exactly slow... and I believe any JAVA program will be slower
than the respective PERL program (there are newbie books for both languages :)

But, perhaps you talk WINDOWS? If so, any software on WINDOWS can be slower
than any other software on WINDOWS... just because they happen to link so some
weird DLL.

Daniel

>>>"Alex Knight" said:
> Not really.
>
> Yes, AWT sucks. Yes, Swing sucks. Java's gui code can be INCREDIBLY lame.
> But for server-side situations, Java can be incredibly scalable.
>
> I wasn't comparing a perl CGI script and a J2EE server, other than saying
> perl simply doesn't offer what J2EE does. Furthermore, I've seen more
> newbies
> write perl cgi scripts in an enterprise environment and break the site
> the minute traffic picks up.
>
> IMHO, scalability is incredibly important, and perl leaves that out often.
> Even with Fast-CGI style servers, perl sucks. Perl is great for admin
> interfaces, or low to medium traffic sites.
>
> -----Original Message-----
> From: Alex Pilosov [mailto:alex(at)pilosoft(dot)com]
> Sent: Friday, August 31, 2001 7:35 PM
> To: Alex Knight
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: [WAY OT] Re: [GENERAL] PL/java?
>
>
> On Fri, 31 Aug 2001, Alex Knight wrote:
>
> > It is generally wiser to split the webservers from the appservers;
> > that will save on memory footprints from each respectively. That alone
> > can give each machine a specific task to accomplish... generally more
> > efficiently. But I would assume you know this.
>
> And it is wise to split database from middleware, and not try to saddle
> PostgreSQL with requirements to support Java in-process. _IF_ java stored
> procedures are implemented, it should be via something like a) oracle's
> extproc (start a separate process to load the function) b) some of perl
> java tools (they start a jdk in a separate process and communicate with it
> using RMI).
>
>
> Problem with java-pgsql integration is the threads model: Java really
> really wants threads. Postgres doesn't do threads. So if most simple way
> is attempted, you will incur overhead of starting up JVM for each backend
> (a few seconds as opposed to milliseconds) and non-shared 30M of memory
> per backend (as opposed to currently <3 megs of non-shared memory per
> backend).
>
> > Using something like WebLogic, WebSphere, or Orion would be a wiser
> > approach. For the company with the low budget, Orion is only something
> > like $2000, and it has full J2EE support, including EJBs, etc. Try
> > finding that kind of richness in Tomcat. Also, Orion takes up only
> > 40-50mb at start, which is really fairly reasonable; ram is cheap
> > anyways... a server that has to perform complicated algorithms to a
> > large audience but has hardly any ram shouldn't be on the internet
> > anyways; unless it can handle it.
>
> _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of
> (non-windows, non-java) software that takes 40-50M just to start up!
>
> I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds
> to start up on P3-800, that, IMHO, is ridiculous.
>
> It is not only issue of memory, its easy to throw memory at the problem,
> its an issue of _incremental use_ of memory. As you scale
>
> > I feel that you don't really have enough experience with _java_ to
> > judge it accurately. Frankly, the JVM is quite small nowadays,
> > considering the amount of base classes that sit in memory much of the
> > time. And the JVMs are really much faster these days. Java is still
> > slow for 2 reasons: 1) Developers who don't optimize their code as
> > they write it, 2) Bytecode interpretation is and probably never will
> > be as fast as something like C/C++. But it certainly isn't the JVM
> > itself slowing it down because of some "extended memory" that it lives
> > in. Any reasonable server should have absolutely no problems if the
> > jvm is implemented _properly_ (which many packages do not do), etc. If
> > you're comparing Java to perl, yes, certainly it's a bit more of a
> > beast, but perl quite simply can't keep up in speed and feature
> > richness (when was the last time you secured your perl code in a
> > redistributable fashion?)
> _WHY_ the heck do all base classes need to be in memory all the time? Why
> are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny
> compared to all the java standard library.
>
> You know what the answer to it is: Because they are ALL written in java,
> as opposed to more sane languages like perl which handcode their "standard
> libraries" or the most important pieces of them in C.
>
Perl is far faster than java in about any practical application I did.
> Again, the issue is not speed of JVM versus PP (perl virtual machine), if
> you did number crunching in perl and java, they would probably be at par.
> Its an issue of standard libraries. They are _horribly slow_. Perl's
> hashtables are a very nice piece of optimized C code. Java's hashtables
> are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog
> and a half, because they reimplemented all the things that are commonly
> done in C in Java.
>
> > The only mistake the developers can make is poorly implementing the
> > jvm, but most certainly not Java itself. I've been working on
> > architecting and building enterprise level sites and applications for
> > nearly 8 years now, and I've seen too many people try to implement
> > perl cgi websites for enterprise sites and watch them choke and crawl
> > to their knees because of poor system resource handling, lack of
> > scalability, etc... I most certainly don't consider a single webserver
> > with an appserver and tiny database to be enterprise level either (not
> > that I'm inferring you said it was).
> You cannot compare a perl CGI script and a J2EE server. Its like comparing
> a webserver you wrote yourself vs apache! There are application servers
> (or more closely, code libraries) for perl that match what J2EE provides.
>
> --
> Alex Pilosov | http://www.acedsl.com/home.html
> CTO - Acecape, Inc. | AceDSL:The best ADSL in the world
> 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
> New York, NY 10018 |
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly