cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuartroeb...@mac.com>
Subject Re: [provocative] resurrecting native code
Date Sat, 16 Feb 2002 14:12:24 GMT
Well, I have to say that I went for Cocoon primarily because it ran 
everywhere and because Java is (in my opinion) much easier to maintain - I 
used to code primarily in C and C++. I realised there would be a trade-off 
in speed to some extent, but to me the trade off is well worth it.

We are developing on Mac OS X and deploying on FreeBSD, and we have no 
problems at all with WORA.

Whilst I have no problem with the idea of allowing JNI based 'plug-ins', 
it would be a very sad day if work spent on making the Java code run 
efficiently was pushed aside in favor of optimizing C or C++ code on 
particular platforms (probably Windows and Linux at the moment).

I appreciate the provocative nature of this email, but I also appreciate 
that there is a big unexplained basis for most of it - the first paragraph.

Could you explain why you have come to the conclusion that WORA is as much 
a problem with Java as with any other programming language in the world?

It certainly isn't my experience.

With regard to optimizing cocoon - I'd guess that caching the results of 
database access would have a massive impact on the performance of the kind 
of sitemaps we are working on.  Most of the pages are always the same 
except on the relatively rare occassions when the data has changed. But, 
at the moment many pages aggregate from four or five sources based on 
database data and the data is checked every single time and hardly 
anything is cached: so all the transforms have to be repeated.  I'm sure 
that having some simple mapping for each database table indicating when it 
was last written to would be sufficient to enable caching that would 
ensure that most pages could be reproduced directly from cache, possibly 
reducing processing time by 9/10 or more!

Stuart.

P.S. Anyone interested in a simple EmailTransformer - i.e. a transformer 
that interprets email descriptions and sends emails, but leaves the rest 
of the document intact?

On Friday, February 15, 2002, at 09:01 pm, Stefano Mazzocchi wrote:

> I've (finally, some would say) come to the conclusion that WORA (write
> once run everywhere) has to do with Java more or less like it has to do
> with any other programming language in the world.
>
> Despite Sun's marketing.
>
> Thus, we (Pier and I) have decided break the unwritten rule "don't mix
> java bytecode with native code" and decided to go resurrect native code
> and use JNI.
>
> Early investigations are *impressive*.
>
> I even venture to say that the right mix of java code and native code
> could well outperform completely native implementations.
>
> This said, I want to throw a stone in the lake and see where the waves
> go:
>
> if Cocoon performance bottleneck is XSLT processing, what about using
> Xalan C as the XSLT processor instead of Xalan J?
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>

            Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
      Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Systems Architect                             Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message