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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Question concerning speedup of , Peter Nilsson | Thread | RE: Question concerning speedup of , Peter Nilsson |
Re: Question concerning speedup of , Frank Wegmann | Date | Re: About DSSSL perception..., Philippe Robitaille |
Month |