Changeset 2507 for docs


Ignore:
Timestamp:
Oct 19, 2012, 7:11:48 PM (7 years ago)
Author:
ksherdy
Message:

Added skeleton text to performance section.

Location:
docs/Working/icXML
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • docs/Working/icXML/performance.tex

    r2500 r2507  
    11\section{Performance}
    22
    3 \icXML{} vs. Original Xerces
     3We evaluate the Xerces C++ 3.1.1, ICXML Xerces C++ XML parser and pipelined
     4ICXML Xerces C++ against two benchmark applications. A key predictor of
     5the overall parsing performance
     6of an XML file is Markup density (i.e., the ratio of markup
     7vs. the total XML document size.) This metric has substantial
     8influence on the performance of traditional recursive descent
     9XML parsers. We use a mixture of document-oriented and
     10data-oriented XML files to analyze performance over a spectrum
     11of markup densities.
    412
    5  -- SAXCount
    6  -- GML2SVG?
     13SSE SIMD extensions have been
     14available on commodity Intel processors for over a decade
     15since the Pentium III. They have steadily evolved with improvements
     16improvements in instruction latency, cache interface, register
     17resources, and the addition of domain specific instructions.
     18Here we investigate XML parser performance
     19evaluated using an Intel Core i7 quad-core
     20"Sandy Bridge" processor (3.40GHz, 4 physical cores/8 threads,
     2132+32 Kb (per core) L1 cache,
     22256 Kb (per core) L2 cache,
     238 MB L3 cache).
    724
    8  -- simulated performance on AVX2???
    9  
     25\subsection{Xerces C++ SAXCount}
     26
     27SAXCount is the simplest application that counts the elements and characters of a given XML file using the (event based) SAX API.
     28The SAXCount sample parses an XML file and prints out a count of the number of elements in the file.
     29
     30\subsubsection{Workload}
     31
     32XX shows the document characteristics of the XML input
     33files selected for the Xerces C++ SAXCount benchmark. The jawiki.xml
     34and dewiki.xml XML files represent document-oriented XML
     35inputs and contain the three-byte and four-byte UTF-8 sequence
     36required for the UTF-8 encoding of Japanese and German
     37characters respectively. The remaining data files are dataoriented
     38XML documents and consist entirely of single byte
     39encoded ASCII characters.
     40
    1041\begin{figure}
    1142\includegraphics[width=0.5\textwidth]{plots/perf_SAX.pdf}
     
    1344\label{perf_SAX}
    1445\end{figure}
     46
     47\subsection{GML2SVG}
     48
     49The visualization of geographic information is a primary goals of on-demand web-based mapping systems \cite{lu2007advances}.
     50Web-based mapping systems commonly encode spatial data with GML for transmission and with SVG for display \cite{lu2007advances}.
     51GML is an XML grammar defined by the Open Geospatial Consortium (OGC) to encode geographical features \cite{lake2004geography}.
     52As an XML grammar, GML is platform neutral and is well suited  the exchange of spatial data over the Internet.
     53GML however, is not a visualization format. Rather, GML relies on commercially available viewers for data visualization,
     54with Scalable Vector Graphics (SVG) viewers being one of the most common \cite{lu2007advances}. Large volumes of GML data are
     55typical in on-demand web-based mapping, and as a consequence, the visualization of GML as SVG requires
     56high-performance GML to SVG translation.
     57
     58In this section we present a performance evaluation of the translation wide spectrum of Geography Markup Language (GML)
     59data files to Scalable Vector Graphics (SVG) format for visualization.
     60
     61GML to SVG Benchmark
     62
     63In the GML to SVG benchmark, GML feature elements and GML geometry elements tags are matched. GML coordinate data are then extracted
     64and transformed to the SVG path data encodings. Equivalent SVG path elements are generated and output to the destination
     65SVG document.
     66
     67\subsubsection{Benchmark Data Characteristics}
     68
     69GML to SVG data translations are executed on GML source data modelling the city of Vancouver, British Columbia, Canada.
     70This data set consists of 46 distinct GML feature layers ranging in size from approximately 9 KB to 12 MB.
     71In this performance study, approximately 213.4 MB of source GML data generates approximately 91.9 MB of destination SVG data.
     72
     73
     74
     75 
  • docs/Working/icXML/reference.bib

    r2490 r2507  
    597597year=2002
    598598}
     599
     600@article{lu2007advances,
     601  title={Advances in GML for geospatial applications},
     602  author={Lu, C.T. and Dos Santos, R.F. and Sripada, L.N. and Kou, Y.},
     603  journal={Geoinformatica},
     604  volume={11},
     605  number={1},
     606  pages={131--157},
     607  year={2007},
     608  publisher={Springer}
     609}
     610
     611@book{lake2004geography,
     612  title={Geography mark-up language (GML)[foundation for the geo-web]},
     613  author={Lake, R. and Burggraf, D.S. and Trninic, M. and Rae, L.},
     614  year={2004},
     615  publisher={Wiley, Chichester}
     616}
Note: See TracChangeset for help on using the changeset viewer.