there might be - for loops are a pretty slow way of accessing an array for
instance (although they look lovely and keep things neat) - it's actually
faster to add each node of an array manually so in theory, the fewer times
the app has to loop through large nests of xml (similar process), the
better.
for really large xml files, i suppose the extra file weight of the extra
verbosity (is that a word?) of a heavy nest over one that makes more use of
attributes might make a difference in load times as well although i think
it'd have to be a seriously large file (or for a seriously slow connection)
to really be a consideration
that said, i would use a child node for large amounts of text / data - you
wouldn't put a whole paragraph into an attribute, for instance. Nor would
you want to put html formatted text into an attribute (i don't even think
you can?)
so:
<?xml version="1.0" encoding="UTF-8"?>
<trainupdate result="success" currtime="1219755890344"
targettime="1220029200000" distance="180" weather="rain" winddir="45"
windspeed="18">
<train position="26" speed="40" departing="Departing 1pm"
stoptext="Leaves on line" />
Here is a paragraph of copy describing the function and focus of the
train in question. I could go on like this for hours. Would you like me to?
</train>
<train position="65" speed="60" departing="Departing 3pm"
stoptext="Signal failure" />
Not as much but we're following a precedent
</train>
</trainupdate>
On Thu, Aug 28, 2008 at 6:05 PM, Matt S. <[EMAIL PROTECTED]> wrote:
> Thanks. Do you know if the difference is dramatic? Just curious,
> especially since most "experts" eg Moock's books dont shy away from
> node-heavy XML generally, but if there are serious performance
> considerations you'd think they would.
>
> .m
>
> On Thu, Aug 28, 2008 at 10:27 AM, allandt bik-elliott
> (thefieldcomic.com) <[EMAIL PROTECTED]> wrote:
> > yes the second one is shorter :)
> >
> > i try to keep child nodes to a minimum - 1 per 'object' and only really
> use
> > them when describing one of several same-level objects
> >
> > On Thu, Aug 28, 2008 at 2:58 PM, Matt S. <[EMAIL PROTECTED]> wrote:
> >
> >> Speaking from recent experience, lots of little XML files is ok if
> >> you're accessing them one at a time, but if you need to pull up more
> >> than one at a time, it can get slow quick. I had a project where I had
> >> to load 5-10 small xmls (really small, just basic image galleries, 10
> >> items max each), and it seemed like the initial process of loading the
> >> XML files (load one, increment xml ID, load the next, etc) was the
> >> lions share of the load time, so that when it was 10 xmls at once it
> >> started to take annoyingly long (especially since that was then
> >> followed by the actual images needing to be loaded). In the end we
> >> compiled all the xmls into one big XML and loaded that up front. But
> >> on other projects, when I was just loading single small xml files one
> >> at a time, it wasnt a problem.
> >>
> >> I would be curious though, my impression from that experience was that
> >> alot of the load time on an XML file comes from that initial loading
> >> of the file, not so much the stepping through the XML, is that
> >> accurate? And is there any difference in load time between this:
> >>
> >> <image>
> >> <path>imageurl</path>
> >> <name>imagename.jpg</name>
> >> <width>800</width>
> >> <height>600</height>
> >> </image>
> >>
> >> vs this:
> >>
> >> <image path="imageurl" name="imagename.jpg" width="800" height="600" />
> >>
> >> .m
> >>
> >> On Thu, Aug 28, 2008 at 9:35 AM, Lehr, Theodore M (N-SGIS)
> >> <[EMAIL PROTECTED]> wrote:
> >> > I have a project that involves xml... I am wondering how I should
> >> > organize my xml... would it be best (from a flash perspective) for it
> to
> >> > be on huge xml file with lots and lots of children - or would I be
> >> > better off breaking it into multiple xml files where one xml tag
> >> > references another xml file and so on...
> >> >
> >> > _______________________________________________
> >> > Flashcoders mailing list
> >> > Flashcoders@chattyfig.figleaf.com
> >> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >> >
> >> _______________________________________________
> >> Flashcoders mailing list
> >> Flashcoders@chattyfig.figleaf.com
> >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >>
> > _______________________________________________
> > Flashcoders mailing list
> > Flashcoders@chattyfig.figleaf.com
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
