What PageMixer is - (6/7)

Performance

Comparison difference around "performance" between JSP, XMLC and PageMixer is shown as below.

Please see "Design note" if you want know detail about how PageMixer reduces cost or why it is designed as described.

"Page data" and "shareness" of it

"Page data" means representatoin of page data in each frameworks. It focuses on design elements of final HTML page image mainlly. And "page data shareness" means that whether the page data once created is shareable safely between threads which may alter it.

In JSP, it is "String" embedded in compiled class from JSP file, and so, is shareable.

In XMLC, it is "DOM tree" generated by compiled class from HTML file. Generator class is, of course, shareable, but "DOM tree", (part of)generator class instance, is not shareable, because structure of tree is not shareable safely by alters.

In PageMixer, it is "sequence of Token" generated by object from HTML file. "Token" is minimum element to represent HTML page. You can consider it as "tag" or "text" in HTML page.

Modification of HTML page is as same as modification of sequence, but later is not as same as modification of source sequence, like that UNIX filter command does not modify input source (e.g.: "grep"/"sort"/"uniq"....).

So, page data(generator object, correctlly) is shareable in PageMixer.

"Cost to create page data"

As described above, page data of HTML page must be created on each processing in XMLC framework, because it is not shareable between threads.

Representation of HTML page must create many objects to build up "DOM tree" in XMLC framework For example, "this page" causes over 500 objects creation in XMLC framework.

According to XMLC release note, XMLC reduces cost of page data creation by "Lazy DOM" mechanism. "Data of Node" may be shareable by it, but "structure of Node" does not seem to be so.

"Processing" and "shareness" of it

"Processing is defined as" is already described in former section.

And "Page processing shareness" means that whether one processing unit can be shareable between processing threads.

In JSP, it, "processing", is part of Java code embedded in compiled class from JSP file, and so, is shareable (correctly, if it does not contain thread un-safe code), and is as same as in XMLC.

But in PageMixer, "processing" must have status to recognize own context in "Token" sequence, so it is not thread safe.

"Cost to create processing units"

As described above, "processing" must be created on each processing in PageMixer framework, because it is not shareable.

But it is not so expensive, because you only need to create at most 50 or near objects even if you divide processing into very small fragments.

And since version 2:

• Filter instance re-usability is increased

  "*Watcher" interface is re-designed.

• reduction of times to create Filter instance

  You can reduce number of Filter construction as same as number of threads at most easily with the base class for presentation Servlet provided by PageMixer.

"Cost to render HTML page"

"Cost to render HTML page" means cost to translate internal representation into byte stream of HTTP response as HTML page.

In JSP, almost parts of page are held as "String" in compiled class ordinarily, so translation cost is very cheap.

In XMLC, renderring of HTML page needs to traverse entire DOM tree representing it, and DOM tree consists of so many objects that cost to do so is very expensive.

In PageMixer, HTML page is represented as collection of many Java objects as same as in XMLC. But it is designed to reduce creation of intermediate "String" objects, so cost of renderring is not so expensive.

"Cost to create new page"

"Cost to create new page" means total cost to create new page.

As described above, JSP is the best solution from the point of view of cost, because both "page data" and "processing" are shareable. "Page data" creation and renderring cost so much that XMLC is the worst one(on my measurement, at least).