-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff Martin <[EMAIL PROTECTED]> writes:
>
> > > Following on from the idea of an event based model it
> > struck me that there's
> > > already a fairly good system for handling even based tree
> > info (Java source
> > > files can be looked at as trees) and that's SAX. So the
> > code I've got here
> > > generates SAX events from a Java source file, it's then
> > should be possible
> > > to apply XSL style sheets to them to view the code in
> > different ways e.g.
> >
> > ... not without any major performance overhead :(
>
> To be honest JXR a the moment it not very good performance wise. It's
> parsing over every line of code 11 times and doing a lot of string
> manipulation which I don't think is the fastest way of doing things. We
> should just be running through the code and then using a renderer to
> actually render the blocks of code into HTML once. This basically leads to
> and event based model. I did start down this route but decided that I'd be
> better of using Antlr to parse the source code rather than trying to write
> my own.
If there are any performance issues with the current version of JXR, they are
implementation issues and not design issues. I was never at a point where I
felt JXR was complete. :(
There are issues with Antlr, isn't Antlr closed source? I am trying to get to
the website now but they are down. I also don't like generated APIs. This is
one of the main reasons not to use something like Castor/Antlr.
> As far as the events go what I think would be needed is something that says,
> "I've started such and such block", "I've finished this block" which is
> basically SAX so even if we never use XML the event model would still fit.
I think that it might be a decent compromise to go both ways. Have an Event
based SAX interface and then an object which just outputs straight HTML. This
way we can have a fast HTML interface and a slower XML -> XSLT interface.
<snip>
> At the moment JXR doesn't seem to check to changed files properly to it
> rebuilds every. I'm sure this is a bug as I've seen comments in the code
> that refer to it doing it, but I 'm not convinced that the current version
> of JXR is maintainable. CodeTransform is doing far to much and it's vary
> confusing to work with.
Yes... I know. I agree that it isn't idea. I do believe that it is the best
combination of performance, readability, etc that I could come up with at the
time. +1 for removing the XML generation.
<snip>
> If we can compile 100 projects, then converting them to HTML should be
> possible. Currently JXR does have a habbit of running out of memory in the
> JVM. In order to scale we'd need to look at persisting some information on
> the file sytem fo that it can be paged.
- -1. This is the concept of virtual memory :). Don't right your own paging
... the OS should do it for you :). It is true that some VMs have problems with
paging this way. They will just terminate if they run out of 'real' memory (IE
not virtual). I don't think this is JXRs fault but the JVMs. A non-VM like GCJ
will not have this problem.
<snip>
> Basically if it works we'll all be over the moon, but if it doesn't we'll
> know why it's a bad idea ;o)
I certainly think a decent compromise is a good idea. We could do HTML
generation every time and then XML-XSLT transformations every 5 times or so.
This way you could have generated content via XSLT but without such a major
performance hit.
> I'm hoping that be deal directly with SAX event and not character streams I
> can maintain a reasonable preformance in the same manner as Cocoon2 performs
> much better then Cocoon1. Also making sure that we keep any XSLs in memory
> removes the overhead of recompiling those.
The other problem is the index. You have to keep that in memory.
> >
> > Do you have any performance metrics you can publish for you
> > code/proposal?
> >
>
> I'll sort somthing out, the test code that's there at the moment does report
> the time taken to run each test, but things are far from optimal at the
> moment.
<snip>
I am a big +1 on the addition of XSLT, I think the best way is to remove the
HTML generation from the current JXR and just tag on a SAX event mechanism, then
you can have a SAX handler that outputs HTML and one that outputs XML for XSLT
or whatever in the future. I think this will add about 4% or so to the
performance hit. This would be due to fact that you have one level of
indirection and this is mostly method dispatch.
Adding Antlr would be a bad idea. Granted it would remove out level of
complexity (we wouldn't have to worry about parsing out Java file) but this
would mean that we have a parser which we don't know anything about. It also
brings in more code that could break. Performance is an issue here too because
we don't know what the performance issues with Antlr are.
That and I still can't get to the site to find out the license :(
Kevin
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
For great justice.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE64P/aAwM6xb2dfE0RAuvaAJ42Km1xBzSRvP+aF1LKbks4J2r2kACeOtbx
XxPAdWX7QvzyScQKq0cNWWw=
=R1A2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
