Re: Performance Problems - More Findings
At 08:17 AM 7/25/01 -0500, Weiqi Gao wrote: >Unfortunately, there is no faster XSL-FO transformers that we can >substitute FOP with (the eval version of The Other FO processor---I >don't want to mention names to make you cross either---seems to be even >slower than FOP at certain inputs). Feel free, I don't think it'll hurt any feelings. :-) I make a practise of using PassiveTeX, AntennaHouse XSLFormatter and RenderX XEP, just so I can get a feel for what the consensus is on formatting and rendering things where the spec allows leeway. The www-xsl-fo list has implementors from all the processors participating. And certainly implementors sometimes share private communications. There is plenty of room for competition. To date I haven't noticed that FOP is slower than the other processors. If anything it is often somewhat faster (subjective impression, I'll admit). I think at this point even the most mature formatters are still more concerned with feature support than they are with speed (memory usage being another matter entirely, of course). Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems - More Findings
On 25 Jul 2001 16:44:47 +1000, Darren Munt wrote: > > As an interim measure, we decided to produce the FO file separately > with another parser (I wont tell you which one, it will only make you > cross) We'll make wild guesses and get cross anyway. You are using MSXML, right? :) [No need to answer.] > and send this straight to FOP. This brought the total rendering > time down from 30 seconds to about 17 seconds, which exceeds the > saving observed by Weiqi earlier when using Saxon. I realize that the time that is spent in XSLT vs. in XSL-FO is dependent on the complexity of the original XML, of the XSLT stylesheet, and of the resulting FO. I could imagine a very simple XSLT working on a very simple XML to generate a fairly complicated FO, as is the case for the AllElements example. Or it could be the other way around. These could change the proportions of the time wildly. If you spend significant time in XSLT, then using a faster transformer makes sense. Unfortunately, there is no faster XSL-FO transformers that we can substitute FOP with (the eval version of The Other FO processor---I don't want to mention names to make you cross either---seems to be even slower than FOP at certain inputs). One thing I tested early on was to interface the XSLT results into FOP in various ways: Stream, SAX, and DOM. And there doesn't seem to be any time savings I can wring out by using a DOM vs. an in memory string wrapped up in a InputSource. FOP parses whatever that's input again anyway. -- Weiqi Gao [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems
Arved Sandstrom wrote: > > > Failing that, if we are talking about compiling with javac or Jikes or > whatever, you are left with compiled bytecode, and for that we have to have > a JVM. No ifs and buts. So then the avenue of inquiry leads down looking at > the Invocation API in JNI. Although I tend to think it might be easier to go the Cocoon2 or HTTP proxy route suggested by Jeremias, I think it should be possible to do this with the Invocation API. Basically you have to encapsulate a VM in your COM object, but once you have it you should be able to use it do multiple FOP calls. I have used this in the past to combine C++ and Java code, in both Mac and Microsoft environments, so it can be done. Just to be clear, this is a Sun JVM I'm talking about; no special MS Java involved. Good luck, Karen Lease - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems
> My confidence level of being able to transition FOP to COM myself is very > low. It would be really nice if someone would take this on :) Or maybe I'm > just being lazy. You said earlier that Cocoon worked for you but you dropped it because it used an older version of FOP. Did you look at Cocoon 2? I think it currently includes FOP 0.18. I think from this version it's just a matter of replacing fop.jar to get the latest version running. I'm sure there are people around who did that already. Maybe you could implement a simple HTTP-Proxy (that calls Cocoon) in place of the code that calls FOP now. Just an idea. Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Problems
>One thing to be careful of is, who is doing the talking about >compiling Java classes as COM components? Whenever I have run >across references to doing this, it's been about using MS Visual >J++ to compile the Java. Of course, the talking has mostly been done by Microsoft. They want to be all things to all people. I hate them but the bastards put food on my table. There are a couple of alternatives available to people stuck in COM land though. You can run a utility that registers a Java class such that it can be called in the same way that we would call a COM object. This evidently involves smoke and mirrors behind the scenes, no doubt needing to start the JVM afresh each time, and probably yeilds no real gains over the command line approach. The other is to compile the Java class as a COM object using Visual J++. Either way, you have to use the Microsoft JVM. My confidence level of being able to transition FOP to COM myself is very low. It would be really nice if someone would take this on :) Or maybe I'm just being lazy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Problems
At 07:27 PM 7/24/01 +1000, Darren Munt wrote: >I'm aware that it is possible to compile java classes as COM components, but >even if I knew where to start on this, I'm not sure it would help much. The >cocoon approach was looking good for us, but we discovered that the version >of FOP that is installed with cocoon does not have the level of FO >compliance that we need. One thing to be careful of is, who is doing the talking about compiling Java classes as COM components? Whenever I have run across references to doing this, it's been about using MS Visual J++ to compile the Java. This may be something you want to explore, nevertheless. I am just pointing out that in this discussion "compile" has different meanings. Failing that, if we are talking about compiling with javac or Jikes or whatever, you are left with compiled bytecode, and for that we have to have a JVM. No ifs and buts. So then the avenue of inquiry leads down looking at the Invocation API in JNI. Sun doesn't seem to be as much help on this as they could. They leaped way ahead and have provided an early-access COM-EJB bridge; if you had FOP all wrapped up inside a session bean you'd be all set. :-) This is interesting and I'll see what I can find out further. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Problems
Jeremias, >That's because you're starting a new VM for every document you're >creating. First the VM is started (expensive operation), then all >classes have to be loaded which also takes a long time. Processing in >Cocoon was faster because all FOP classes were already loaded after the >first call. I figured that might have at least contributed to the problem, but I did not realise that it would be such a big factor. I'm not a Java programmer by a long shot and this is the first time I've tried to use it in the real world (outside of Uni). >How to improve your situation depends on how FOP fits into your project. The PDF component of the app is very small, it creates only a single report and the app does much more than this. What happens is the user requests a hard copy of a particular report, which we then have to create on the fly and stream to the browser. FOP works brilliantly for this, but for the processing time. >If your application is written in Java... Unfortunately it is not. It's written in ASP/Visual Basic. This is not the place to discuss the relative merits of development platforms, but for some very good reasons, this was a good choice for us. At least here in Australia, COM based apps, and programmers who can write them, are common enough. The problem is, no-one in the COM world has done what you guys have done with FO. I'm aware that it is possible to compile java classes as COM components, but even if I knew where to start on this, I'm not sure it would help much. The cocoon approach was looking good for us, but we discovered that the version of FOP that is installed with cocoon does not have the level of FO compliance that we need. It may be that I need to bring on board a Java programmer to sort this out (I'm getting too old to learn new tricks). I guess I was hoping that someone might have already achieved a COM installation that works, or that there would be some other easy resolution. Thanks for the pointers anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems
> I've noticed a bit of chat on the list the last few days concerning > performance. I'm having a few problems in that area and I wondered if anyone > had any suggestions. I have a 16 page document, consisting of text and > embedded images, which is presently taking 30 seconds to generate. I've > tried Mark's Fop.jar, which saves me about 4 to 6 seconds on this, but it > still seems excessive. I think it has everything to > do with the way I am invoking FOP. > > I'm calling fop from the command line, using the runnable Jar. The call > looks like this: > > d:\jdk\bin\java.exe -classpath > d:\jdk\lib\tools.jar;d:\jdk\lib\classes.zip;d:\fop\lib\ant.jar;d:\fop\lib\w3 > c.jar;d:\fop\lib\buildtools.jar;d:\fop\lib\xerces-1.2.3.jar;d:\fop\lib\xalan > -2.0.0.jar;d:\fop\lib\xalanj1compat.jar;d:\fop\lib\bsf.jar;d:\fop\lib\jimi-1 > .0.jar;d:\fop\fop.jar;d:\fop\lib\xerces.jar;d:\fop\lib\xalan.jar;d:\fop\lib\ > bsf.jar -jar d:\fop\fop.jar -xml test.xml -xsl test.xsl -pdf test.pdf > > The class path came from the RunTest.bat, which was the only example that I > could find at the time. There's probably all sorts of things in there that I > don't need. > > When we first started playing with FOP, it was with Cocoon. The document we > were testing with was only 5 pages, but the processing time was much less, > only a few seconds. Because the cocoon distributable didn't cme with the > latest FOP, and we wanted to use v0.19, we went for the command line option. > It also fits in better with how we are using FOP. > > I apologise for being a Java ignoramus, but can anyone give me a pointer on > what might be happening here? That's because you're starting a new VM for every document you're creating. First the VM is started (expensive operation), then all classes have to be loaded which also takes a long time. Processing in Cocoon was faster because all FOP classes were already loaded after the first call. How to improve your situation depends on how FOP fits into your project. If your application is written in Java, I encourage you to look at http://xml.apache.org/fop/embedding.html to see how to embed FOP into your application. Of course, that means taking fop.jar and a few other jars into your project class path. Unfortunately, the page above only shows how to call FOP. The part where XSLT comes into play is missing. I think you will find material on that in the mailing list archive. Probably, this page will have to be improved. Volunteers? Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
