Hi all,
I am writing codes to generate a NotesDocument with a tailor-made table(diff cell color, merged cell) by DXL.
I found out using DXL to generating document with table is much slower than by using LS-RT table, especially when the table size is large.(9 sec vs 2 sec for 52row*16col table) However, DXL offers more flexible controls on complex table-making.
Is there any way to optimize the DXL codes?
Thanks
Sam
Subject: Dynamic Table, DXL and performance
If you really want performance and control over rich text at the same time, DXL isn’t going to work well for you, and neither will the native LS rich text classes. Both are just way too slow. If you need performance, you either need an API solution, which will be pretty complex to write, or a third party product such as our Midas Rich Text LSX, which combines high levels of flexibility with extremely high performance.
As an example, I tried creating a table such as you describe, with different cell colors and merged cells and 52 roiws and 16 columns. I tried once creating the whole table at one call (without the merged cells), and another where every row was created separately to allow merging and changing various cell attributes. In both cases, creating a single table was too fast to measure, so I created 100 separate documents with a table such as this in each.
Midas Rich Text LSX times
Table created in one call
Table created a row at a time
100 documents
4 seconds
15 seconds
As you can see, well under a second is better than either the 9 seconds DXL takes or the 2 seconds the LS RT classes take. Of course, you may not need that level of performance, but if you are creating 25,000 documents and doing other processing (as a recent customer described), you might want it to complete in less than the 62.5 hours that the DXL processing would require, or even the almost 14 hours the rich text classes would take, even if they could handle this. The customer’s job is slightly different, but does involve appending large tables a row at a time, and they report that the task runs in a bit less than 1 hour, even with all the additional processing.
Subject: RE: Dynamic Table, DXL and performance
Hi Ben,
Thanks for your reply.
I think Notes should take your LSX product as the default development tool as the BASIC richtext table controls in Notes 6 are really really limited…
Sam
Subject: DXL Import performance for tables is MUCH improved in 7.0
I don’t buy the assertion that DXL is always going to be a slow solution. Admittedly, we had some horrific performance problems in the 6.x implementation which prompted us to refactor parts of the Importer for 7.0. The biggest problems indeed were in tables. If you or someone can try the same example on 7.0 I think you will be very pleased with the performance.
Unfortunately, the refactoring work was too extensive to backfill to 6.x.
Subject: RE: DXL Import performance for tables is MUCH improved in 7.0
I assume your response was to Andre, since I never said DXL would always be slow. In any case, I’m glad to hear you have refactored the table import, which was really, really slow (although I still can’t believe 9 seconds isn’t a mistake).
Sam, if you could try this on ND7, I’d be interested to hear what you find. If IBM could make this faster than the Notes rich text classes, it would be the basis for a lot of interesting projects.
Subject: RE: DXL Import performance for tables is MUCH improved in 7.0
I don’t want to split hairs, but my response was where I wanted it to be. It was in reponse to your post that said things like:If you really want performance and control over rich text at the same time, DXL isn’t going to work well for you, and neither will the native LS rich text classes. Both are just way too slow.
As you can see, well under a second is better than either the 9 seconds DXL takes or the 2 seconds the LS RT classes take.
… you might want it to complete in less than the 62.5 hours that the DXL processing would require …
In retrospect, the only wording that I object to is “Both [DXL and native LS rich text classes] are just way too slow”. Try the 7.x Importer and I’m not sure you’ll still be saying that. I have to admit, I took your “62.5 hours” comment out of context. I read it quickly as a sarcastic generalization, whereas it was an accurate computation as to how long DXL would take to process 25,000 documents with 52x16 tables. Your points are on for 6.x so the only point I am really making is don’t write off DXL in general because of performance, because it should be much better (for Importing) in 7.0. And if people will report performance problems officially, we can strive to fix them.
Subject: RE: DXL Import performance for tables is MUCH improved in 7.0
I appreciate your comments. You are correct that I was presumptious to assume that DXL rendering could not get faster, as obviously it could and has. I greatly appreciate your efforts in this regard. This may seem disingenous given that I have what could be seen as a “competing product”, but frankly, the majority of our revenue does not come from table manipulation anymore, but rather from HTML import and export and other features which would not be challenged much by DXL import/export. In those regards, I simply appreciate IBM’s validation of the notion and viability of rich text manipulation. If the DXL importer gets better, that allows more projects and products that use DXL manipulation as a viable alternative to Midas, but it also allows people to use rich text with confidence that it works well in Notes, and the greater the use of rich text and rich text manipulation in Notes/Domino, the bigger our market. I tell lots of people to use DXL for basic rich text manipulation now, but I have hesitated in the past to recommend that for table manipulation because of the performance issues. I’ll certainly test and hope I can recommend DXL for that as well in the future.
In the meantime, I would love to see the actual code used for this test and have that run in ND7. It would be good to add that as a comparison to the chart I listed.
Subject: RE: Dynamic Table, DXL and performance
No way to make DXL importing faster that I know of, but perhaps you could do something to make sure the code you’re using the generate the DXL is optimized. Since it is a two-step process, you could test to see where the time is being spent.
Also, you might look into MIME as an alternative.