Re: [xml] Profiling and possible speed improvements
- From: Daniel Veillard <veillard redhat com>
- To: Bjorn Reese <breese mail1 stofanet dk>
- Cc: xml gnome org
- Subject: Re: [xml] Profiling and possible speed improvements
- Date: Wed, 24 Apr 2002 13:41:27 -0400
On Wed, Apr 24, 2002 at 05:32:12PM +0000, Bjorn Reese wrote:
Daniel Veillard wrote:
Hum, this definitely sounds interesting, one should add the following
Before switching to Quick Sort, I would strongly suggest that empirical
data is collected on typical input sizes of stylesheets.
Shell's Sort was chosen because it is fast on small to medium data sets
(this was one of the improvements we made for XSLTMark). IMHO, we should
yes, I remember that.
be cautious about gaining better performance of large data sets at the
cost of typical data sets.
Seems that we would need to keep the Shell's Sort for target where
qsort is not available or broken (I have had hell in the past for rpm2html
use of qsort on some old Solaris)...
Maybe the trade-off is to use either depending on the size of the
set of the node list to sort.
Also, there are plenty of alternatives to the two mentioned sorting
algorithms. Further examples, of which some may be interesting to
examine, can be found at:
http://www.cs.ubc.ca/spider/harrison/Java/sorting-demo.html
http://cs.smith.edu/~thiebaut/java/sort/demo.html
http://www.diku.dk/users/jyrki/Experimentarium/
There is, however, another good reason to replace Shell's Sort. It does
not preserve the original order of equal entries.
Is that an XSLT requirement ?
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]