From malsburg at gmail.com  Fri Feb 10 19:12:45 2012
From: malsburg at gmail.com (Titus von der Malsburg)
Date: Fri, 10 Feb 2012 19:12:45 +0100
Subject: [Rd] Creating XML document extremely slow
In-Reply-To: <1328895785.2325.37.camel@milan>
References: <CAM+LvrA9pWspU2qTMf4dJTbxFZzS9waDLTbHtHU=0GiJYwD4dA@mail.gmail.com>
	<1328879419.2325.8.camel@milan>
	<CAM+LvrAY7OCUOk8fZyBmQw+ZnA4U296Q84MLA4nVLCKyrA6Lgg@mail.gmail.com>
	<1328895785.2325.37.camel@milan>
Message-ID: <CAM+LvrD9eoL-wHjNzk3K0NOjU6488NwjXUSOOKo--ArMfJAMsg@mail.gmail.com>

On Fri, Feb 10, 2012 at 6:43 PM, Milan Bouchet-Valat <nalimilan at club.fr> wrote:
> Doesn't sound so bad to me. I don't think you'll find a use case where
> 3s will really be a problem.

Actually I have exactly such a case because I have to produce many
such documents and a difference of two orders of magnitude in
processing matters greatly.

> From what Rprof() says, xmlNode() doesn't seem to do anything obviously
> wrong. It's just that you're calling it 500 times, so there's some
> overhead. You'd need a vectorized version that would handle all the data
> in one go

My code that patches together strings is also not vectorized and does
something in 500 iteration.  Still it is 300 times faster than the
solution that uses the XML package.  Also, I could only bring down the
processing time of the code that uses XML package to 3 seconds because
(i) the amount of data that was very small and (ii) because the XML
document had a very repetitive structure.  Documents with a more
varied structure don't allow the kind of optimization that you
proposed and if they have a non-trivial size the processing time can
easily become prohibitive.

Anyway, my problem is solved because I'm switched to my own homebrewed
xml generation and it works fine.

  Titus



[Rd] Creating XML document extremely slow
Titus von der Malsburg