RE: Question concerning speedup of Jade

Subject: RE: Question concerning speedup of Jade
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Fri, 7 May 1999 08:31:51 -0400
Hi Peter,

<Comment>
The scheme code (style sheet) is actually compiled after it is loaded, so
it probably won't be hard to write the "byte code" (Insn objects) out to a
file and read it in the next time the style sheet is needed. But I don't
know how much time that would save in comparison to the actual grove
processing/fot construction. In fact, we could mmap the compiled code and
run it directly avoiding to build the Insn tree in memory
</comment>

<reply>
This would simply mean to create all C++ and structures on a) a memory
mapped file, b) an object database. This way, all objects instead of being
created on the transient heap would be created on a permanent
memory/storage. This would accelerate these points:

a) parsing of the DSSSL script
b) instantiation of C++/ structure objects

Would remain for each document:
a) the SGML/XML document parsing
b) the Grove building

However, for some type of documents like, for instance, Electronic
Interactive Technical Manuals (IETM), The grove could be already created and
store in a permanent storage. Thus, in this case, we can also skip the
document parsing.

Here is what Jade is doing:
a) parse the DSSSL script and build C++/structures mostly on the heap.
b) parse the document a build a grove on the heap
c) navigate the grove and fire rules (i.e. element procedures)

If we suppress a) from the process chain we removed a good part of the
process (parsing - objects construction). To do so would imply to overload
the "new" operator so that objects would be created not on the heap but on
an other more permanent memory/storage like for instance a memory mapped
file (or an object DB like for instance PSE C++). So that instead of
re-parsing the script, the memory mapped file is re-loaded in memory, all
the objects are already there. The only "overhead" then is to re-initialize
all objects. This could be added at the end of a process (actually after a
process all objects are destroyed from the heap)

Drawbacks:
Some OS like Linux do not have yet the concept of memory mapped file. Some
OS like Solaris, or NT have memory mapped file provisions (I do not know for
AIX, IRIX, Ultrix, OS2, NextStep). Memory mapped file object data base are
not present on all platforms. For example PSE C++ is only available on
Windows. If someone knows about a multi-platform memory mapped ODB or memory
mapped file vendor, this could resolve the case. However, Jade would not be
free anymore. However, the memory mapped file, if present on the target OS,
memory mapped file could to retained as a solution

But Jade do not have the concept of byte code. It is internally a big bunch
of objects created on the heap (on on the stack) like any other C++ program
has.

Hope this was not too technical :-)

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

-----Original Message-----
From: owner-dssslist@xxxxxxxxxxxxxxxx
[mailto:owner-dssslist@xxxxxxxxxxxxxxxx]On Behalf Of Peter Nilsson
Sent: Wednesday, May 05, 1999 3:21 PM
To: dssslist@xxxxxxxxxxxxxxxx
Subject: Re: Question concerning speedup of Jade


On 4 May 1999, Joerg Wittenberger wrote:

> I believe this would be a worthy extension.  Some kind of
> cacheing/precompiling/memoized construction of the style.  Building
> the transformation spec out of DSSSL source can obvoiusly be quite
> complicated.
>
> Unfortunately I don't have an idea whether this is feasible in jade.
>
A way to check if this would save time is to log what jade is doing
"parsing", "compiling", "building fot"... (Poor man's profiling) Anyone
with an enough slow computer who want to do this and check?

/Peter
machine would like

--
'(?P . (?e . (?t . (?e . (?r)))))


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread