MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Circle and Polygon
On second thoughts, perhaps this issue with large files is something
that needs some sort of addressing.
Taking CAP as an example - the examples in the spec doc are fairly
short. Someone may lean towards testing these with a DOM parser + schema
in order to build an application, and 'ship it' because it appears to
work fine. Trouble comes later due to the (as Carl points out) fact that
we don't know what amount of data will be in the files we receive.
This is something I believe should be pointed out in the spec documents.
Cheers
Kon
On Fri, 2005-06-10 at 09:55 -0700, Kon Wilms wrote:
> Nod. It had to be mentioned, was all.
>
> Cheers
> Kon
>
> On Fri, 2005-06-10 at 11:36 -0500, Bullard, Claude L (Len) wrote:
> > The DOM parser may be the wrong implementation approach.
> > A SAX-like parser (eg, XMLReader) is a way one handles
> > large documents. It is harder to implement but much
> > faster. The problem one wants to avoid is premature
> > optimization of the wrong piece of the technology.
> >
> > len
> >
> >
> > From: Kon Wilms [mailto:kon@datacast.biz]
> >
> > That issue is not uncommon. Its standard practice for most DOM parsers
> > to load the entire XML file into memory before parsing. Get a few of
> > those going with threads and RAM decreases fast. I am sure that everyone
> > using fast desktop workstations with a gig of ram don't even notice it.
> > The little guys with 64MB of RAM on an embedded system do, however.
> >
> > This would be about the time where I wave my 'split the resources into
> > separately referenced files' flag.
> >
> > Ofcourse, this could also be purely a speed issue with some code that
> > needs optimization.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]