x2408.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Performance and profiling</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.77"><LINK
REL="HOME"
TITLE="Design and Implementation of a validating XML parser in Haskell"
HREF="index.html"><LINK
REL="UP"
TITLE="User handbook"
HREF="a2283.html"><LINK
REL="PREVIOUS"
TITLE="Check the XML parser with the XML Test Suites"
HREF="x2380.html"><LINK
REL="NEXT"
TITLE="MIT License"
HREF="a2458.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Design and Implementation of a validating XML parser in Haskell: Master's thesis; 
			University of Applied Sciences Wedel
		</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x2380.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Appendix A. User handbook</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="a2458.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="AEN2408"
></A
>A.6. Performance and profiling</H1
><P
>&#13;		Time and space profiling is very useful to optimize programs and remove bottlenecks. We already added the ability of profiling to the XML parser, but did not use this information yet. The main focus of the parser lays on a clear and easy design at the moment.
		</P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="AEN2411"
></A
>A.6.1. Usage information</H2
><P
>&#13;			The validating XML parser can be analyzed with the time and space profiling system of the Glasgow Haskell Compiler (GHC). Cost centers have been added for all main computations, so that it could be measured which parts of the parser consume most time and memory.
			</P
><P
>&#13;			The tool <TT
CLASS="literal"
>Profiling</TT
> can be used to run these tests with the XML parser. It can be built by executing <TT
CLASS="literal"
>make Profiling</TT
> in the root directory of the Haskell XML Toolbox.
			</P
><P
>&#13;			<TT
CLASS="literal"
>Profiling</TT
> must be executed with an XML file as test input and several different parameters that influence GHC's profiling behavior. These parameters are described in depth in the documentation of GHC.
			</P
><P
>&#13;			Four predefined profiling types have been added to the <TT
CLASS="literal"
>Makefile</TT
> in the root directory of the Haskell XML Toolbox. The input file of <TT
CLASS="literal"
>Profiling</TT
> can be set by the variable <TT
CLASS="literal"
>PROFILING_INPUT</TT
>.
			</P
><P
></P
><DIV
CLASS="variablelist"
><P
><B
>Predefined profiling targets:</B
></P
><DL
><DT
><TT
CLASS="filename"
>make runprofiling1</TT
></DT
><DD
><P
>&#13;						Time and allocation profiling - Generate profiling information in XML format and display them with the tool <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>ghcprof</I
></SPAN
> of GHC.
						</P
></DD
><DT
><TT
CLASS="filename"
>make runprofiling2</TT
></DT
><DD
><P
>&#13;						Time and allocation profiling - Generate profiling information in text format and display them with <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>less</I
></SPAN
>.
						</P
></DD
><DT
><TT
CLASS="filename"
>make runprofiling4</TT
></DT
><DD
><P
>&#13;						Heap profiling - Break down the graph by the cost-center stack which produced the data.
						</P
></DD
><DT
><TT
CLASS="filename"
>make runprofiling4</TT
></DT
><DD
><P
>&#13;						Heap profiling - Break down the graph by the retainer set.
						</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="AEN2447"
></A
>A.6.2. How to interpret the results</H2
><P
>&#13;			This section will show how to interpret the results from the profiling tests. The W3C Recommendation of the Extensible Hypertext Markup Language (XHTML) and its Strict DTD was chosen as test input. The test machine was a Pentium 4 with 1.6 GHz and 256 MB memory, running Debian 3.0.
			</P
><P
>&#13;			The results from time and space profiling show that most time and memory is consumed by the function <TT
CLASS="function"
>procesDTD</TT
>. This function provides substitution of parameter entities in the internal and external DTD part. The next resource intensive function is <TT
CLASS="function"
>parseXmlDoc</TT
> that does the parsing of an XML document and constructs an <TT
CLASS="literal"
>XmlTree</TT
> representation from it.
			</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="programlisting"
>&#13;total time  =        1.26 secs   (63 ticks @ 20 ms)
total alloc = 102,664,004 bytes  (excludes profiling overheads)


COST CENTER                    MODULE               %time %alloc

processDTD                     HdomParser            27.0   45.6
parseXmlDoc                    HdomParser            19.0   29.3
buildAllValFcts                DocValidation         14.3    5.0
validateAttributes             DTDValidation         12.7    0.5
processGeneralEntities         HdomParser             7.9    9.6
MAIN                           MAIN                   6.3    5.0
buildAllTransFcts              DocTransformation      4.8    1.8
IdVal.validateIds              Validation             4.8    1.1
validateElements               DTDValidation          3.2    0.2
getXmlContents                 HdomParser             0.0    1.1
			</PRE
></TD
></TR
></TABLE
><P
>&#13;			The ranking of the cost centers might have changed dramatically if the profiling tests are performed with other documents. In this case, parameter entities are exhaustively used in the Strict DTD of XHTML. It is not astonishing that the function that handles their substitution takes the most time and space. Another important aspect is the ratio of the DTD subset and the document subset. If for example the DTD subset is very large, its processing functions might take a large percentage of time and space consumption, too.
			</P
><P
>&#13;			Heap profiling produces graphs that show the memory consumption of the cost centers during execution time. These graphs show very clearly how the program execution behavior of Haskell programs differs from programs written in imperative languages. Haskell uses lazy evaluation when evaluating expressions. Arguments to functions are evaluated only when they are needed. Functions only calculate their result as much as it is needed by other functions that called them.
			</P
><P
>&#13;			Lazy evaluation leads to the fact that Haskell programs do not have a strict sequential evaluation order, but that they resemble a stream. The graphs show very clearly this execution behavior. First the parsing functions are started, after producing enough output, processing of the DTD starts. In the end the validation process starts calculations. The graphs show that almost all functions work in parallel after they have enough input.
			</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x2380.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="a2458.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Check the XML parser with the XML Test Suites</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="a2283.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>MIT License</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>