[sword-devel] proposed patch: adding n=X marker content to footnotes and xrefs
karl at kleinpaste.org
Sat Feb 4 11:34:09 MST 2012
Quite a while ago, Xiphos gained the capability to post-process the
*n/*x that come out of the engine so as to add the n=X identifiers that
emanate out of OSIS and ThML markup. This is a fine and welcome idea,
but we have run into a problem.
Some modules have single-section content that is really big. I mean,
*really* big, half a megabyte at a time Really Big. Notably,
EarlyFathers' /NPNF109/Subject_Index is my current problem child and
The problem presented by a post-processing step of this sort is that,
having the content in hand, we now need to make 2 calls to
getEntryAttributes() in order to retrieve both "n" and "type" elements.
Evidently, each such call requires that the engine retrieve original
content from disc, and fully parse it out. Ouchie.
/NPNF109/Subject_Index has almost 2500 footnotes in its 480Kbytes.
Ergo, 5000 retrievals times 480Kbytes apiece = ...
Ow. Ow ow ow ow ow.
Some rough timing when I discovered this problem earlier this week
showed that it would take -- I am not exaggerating -- just short of an
hour to render this section, on the rather beastly machine I now use.
95+% of the time is being spent in the engine's retrieval; virtually no
time is spent in the g_string routines that perform the actual textual
So although the post-processing effect is a good one, being implemented
*as* a post-processing step is a disaster. I had never noticed this
downside until I ran into these pathological cases this week. The Right
Way to do this is for the filters to output the n=X content on the spot.
The attached patch provides this for all htmlhref and xhtml filters.
I'd like to apply this (I'll do it myself, I have privs) but I wanted to
make sure that adding this doesn't harm anyone else. It's a
straightforward, simple change, and you can see the effect in a couple
Please review and provide feedback. I'll commit the patch in a day or
three if no one objects.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 14749 bytes
Desc: proposed patch: n=X content added to *n/*x
More information about the sword-devel