Re: Speeding up creation of NSDictionary from XML? (iTunes related)
Re: Speeding up creation of NSDictionary from XML? (iTunes related)
- Subject: Re: Speeding up creation of NSDictionary from XML? (iTunes related)
- From: Michael Rothwell <email@hidden>
- Date: Thu, 10 Nov 2005 22:01:08 -0500
I neglected to include the link to the main benchmark page, which is
here:
http://xmlbench.sourceforge.net/results/benchmark/index.html
-M
On Nov 10, 2005, at 9:57 PM, Michael Rothwell wrote:
Here's some chart of an xmlbench benchmark done in February 2004:
http://xmlbench.sourceforge.net/results/benchmark/XMLBench200402-
Draw_html_493737de.gif
http://xmlbench.sourceforge.net/results/benchmark/XMLBench200402-
Draw_html_m4be06c2d.gif
LibXML seems to actually be faster than Expat in at least a few
cases, according to the results.
-M
On Nov 10, 2005, at 9:05 PM, John Stiles wrote:
You seem to be running under the logic that one open-source XML
parser is going to behave exactly the same as another.
However, in reality, Libxml tends to be 2.5-4.0x slower than Expat
in real world use.
Google around for charts if you like, or just try it yourself and
see.
On Nov 10, 2005, at 5:54 PM, Michael Rothwell wrote:
On Nov 10, 2005, at 1:12 PM, John Stiles wrote:
You could try using an open source XML parser like Expat and
parsing it yourself. It will be a bit more code, but not a ton--
you can integrate Expat with your app with only a page or two of
code. It just takes a few function callbacks for "tag opened,"
"tag closed," "character data," etc etc. This will give you a
lot more control over how your XML parsing time is spent.
Another option would be to move the XML parse into a separate
thread. This won't make things faster, per se, but it will let
the rest of your app start up gracefully--and on a dual-CPU
machine you can get other tasks done simultaneously as the XML
parses. Of course, if you can't do anything meaningful until the
XML is done parsing, this still isn't a big help.
Apple's XML parser is, in fact, an "open-source xml parser" -- or
a wrapper on one, at least. They use libxml (xmlsoft.org). So,
libxml is available for your to use directly to do, for example,
a SAX parse of the iTunes file. However, the iTunes file is
large, and processing that much text simply takes time. Using
xmllint on my iTunes library file on my 1GHz G4 powerbook takes
right at 2 seconds.
This minimal program takes 1.35 seconds on average to parse my
library file (5.3MB):
#include <stdio.h>
#include <libxml/tree.h>
#include <libxml/parser.h>
int main(int argc, char **argv)
{
if (argc != 2)
return(1);
xmlDocPtr doc = xmlReadFile(argv[1], NULL, 0);
}
Using mmap seems to reliably take just a little longer, about 1.4
seconds:
#include <stdio.h>
#include <libxml/tree.h>
#include <libxml/parser.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
int fd;
struct stat s;
char *data;
xmlDocPtr doc;
if (argc != 2) exit(1);
if ( (fd = open(argv[1], O_RDWR)) == -1)
{
perror("open");
exit(1);
};
if (stat(argv[1], &s) == -1)
{
perror("stat");
exit(1);
};
data = mmap((caddr_t)0, s.st_size, PROT_READ, MAP_SHARED, fd,
0);
doc= xmlReadMemory(data, s.st_size, NULL, NULL, 0);
}
Using a thread is probably your best bet to maintain program
interactivity.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blizzard.com
This email sent to email@hidden
--
Michael Rothwell
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Michael Rothwell
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden