XML-Performance in Flash

[commander-x]

Mal eine allgemeine Frage zum Thema XML in Flash (das Thema ist hier bestimmt schonmal angesprochen worden - leider erschwert sich die Suche nach dem Stichwort XML etwas schwer, wenn der Suchbegriff mindestens vier Buchstaben voraussetzt ;-)

Im Prinzip arbeitet Flash ja scheinbar immer noch sehr lahm, wenn es um das Parsen und bearbeiten von XML-Daten geht.
Bis zu welcher Menge ist es eigentlich sinnvoll, mit XML zu arbeiten, wenn man "Menge" vielleicht in KB definieren kann bzw. zum anderen die Anzahl von Knoten.

Im Prinzip arbeite ich zur Zeit mit einer Alternativlösung aus zusammengesetzten Strings, die über Flash generiert werden und wieder später nach einer bestimmten logik wieder auseinandergepflückt werden, wie z.b. als beispiel sowas:

bla, blub§271,482§350,336§235,443§471,463§445,497

Sicherlich nicht sehr elegant, aber weniger performancebelastend und es funktioniert halt.

Zu beachten ist sicherlich die steigende Datenmenge, wenn diverse Knoten dazukommen würden, bei einer möglichen Umstellung.

Ab wann ist es nun überhaupt sinnvoll, die XML-Funktionen in Flash zu benutzen?

Vielen Dank!

[nky]

dAb wann ist es nun überhaupt sinnvoll, die XML-Funktionen in Flash zu benutzen?

Immer dann wenn ein standardisierter Austausch von Daten erforderlich ist.

XML ist lahm - aber sehr ausdrucksstark...
muss jeder für sich selbst abwägen...
ich bevorzuge auch in den meisten Fällen Deine Lösung...
weil schneller... Trennzeichen || Doppelpipe *g
kommt aber auf den jeweiligen Sachverhalt an...

Gruss nky

[commander-x]

schon klar, wann es sinnvoll ist ;-)

aber wegen performance:
ist die Performance dann eher von den zu parsenden Knoten oder doch eher von der Gesamtmenge an Daten abhängig?

mal trivial:

a) ein knoten mit 1000 zeichen

b) oder 10 knoten mit 100 zeichen

macht es einen unterschied?

[nky]

ähem es geht hier in erster Linie mal um die Anzahl der Zeichen....
bei XMl brauchst Du halt einfach mehr Zeichen zum übertragen als durch andere Sachen...zb(CSV)
dadruch die schlechte Performance.....welcher Teil deines XMLS wie aufgebaut ist spielt erst später beim auslesen ne rolle...

wobei
a) ein knoten mit 1000 zeichen

b) oder 10 knoten mit 100 zeichen

Stell Dir mal vor Du bist ein Suchalgorithmus....
wenn du jetzt den Konoten "heinz" suchst und bist bei fall a - kannst du sagen der isses nicht - beachte ich die 1000 zeichen halt nicht...

bei b muss du den ersten knoten prüfen - ist das heinz ? - nein....also den zweiten knoten prüfen....ist das jetzt "heinz" ? auch net....und den nächsten...

du siehst bei Fall B hast Du einen viel größeren Aufwand zu suchen (rein logisch) wie bei Fall a.....

Klar ?

Gruss nky

[commander-x]

rein logisch betrachtet ist es schon klar...aber bei flash kann man sich manchmal nicht immer so sicher sein ;-)

na trotzdem danke! ich werds mal abchecken, ob es sinnvoll ist, mal eine xml variante, entsprechend meines vorhandenen datenvolumens zu nehmen.

[kelor]

es ist einfach wirklich so, dass ab einer gewissen zeichenanzahl xml nicht mehr das richtige mittel ist.

nicht nur die lademenge das auslesen...nein auch die datenmenge, die dann in deinem flash rumfliegt ist verheerend

wenn ich bedenke was für einen aufwand ich in xml betreiben muss, um folgendes dargestellt zu bekommen:

superObj=[];
myObj ={__name: 'hans', alter:35, groesse: 184, geschlecht: m};
 
superObj.push(myObj); 

wird´s schon arg...und das mal kurz potenziert, da bist du dann bei unverhältnismäßig...


greetz

kelor

[commander-x]

gilt das eigentlich auch noch für flash mx 2004? angeblich soll die performance ja allgemein besser geworden sein, aber auch für die xml-funktionalitäten?

es ist irgendwie schade, das diese funktionen zwar vorhanden sind, aber aufgrund der performance kaum genutzt werden können.

eine xml struktur macht sich einfach schöner als ein zusammengesetzter string mit festgelegten trennzeichen und ist natürlich auch flexibler und übertragbar auf andere applikationen.
da nehme ich auch gerne einen mehraufwand in kauf.

allerdings steigt natürlich wieder die datenmenge durch die knoten-tags.

macromedia bitte gib uns mehr performance ;-)

[nky]

zum vergleich:

ich hab ein Schallplattenarchivierungssystem geschrieben in
Flash MX und MX 2004 jeweils (als Test)
http://www.nkylab.de/tutorials/mas/mas.html

edit such mal nach artist :air
dann siehste oben rechts die zeit die flash mx dazu braucht...
bsp unter 2004 hab ich leider net online.....


abfragesprache XPath...

für 330 Records mit Flash MX ->10 Sekunden auf nem 500er Pentium
für 330 Records mit Flash MX2004->2 Sekunden auf nem 500er Pentium

mit 2004 auf nem 2 Gigahertz Rechner...siehste praktisch keinen Preloader

2004 ist perfers schneller geworden....aber ich benutz es trotzdem net

Gruss nky

[kelor]

es ist definitiv viel schneller...bzw. der player iss schneller geworden...

aber wie oben schon erwähnt macht mich einfach der datenmüll, mit dem man zugeschüttet wird, wenn die xml beginnt aufzublähen, wahnsinnig...

bin aber auch gerade dabei an eine rerweiterten xml-klasse zu basteln...bzw. bin praktisch fertig, um sie in einem projekt einzusetzen...nimmt ein paar gedankengänge von xpath mit auf...

greetz

kelor

[commander-x]

scheint ja dann mit mx 2004 wirklich schneller geworden zu sein.
und 330 knoten werden es bei mir noch lange nicht sein...wird sich eh über einzelne Dateien verteilen.

ein 500er ist natürlich schon für heutige verhältnisse nicht mehr schnell, arbeite sonst mit 1,3 oder 2 ghz und die setz ich mal als maßstab an.

bei 330 records ist es übrigens echt schwer mal was zu finden ;-)

[nky]

jaa die XML Klasse
Ich würd sagen bis heut abend dann


Achja um doch noch was sinnvolles zu sagen....
XML mit flash zu parsen macht bei größeren Mengen wohl echt keinen Sinn mehr.....denke ich fast auch....
ich würd sowieso immer die (schnellere) PHP Lösung vorziehen- und nur das an den Client geben was er braucht...
es sei denn es sind nur kleine xmls ....da isses schon wieder richtig geil das flash das kann..kommt halt echt auf die menge an....

Gruss nky

[nky]

schwer was zu finden ? das system ist für nen freund von mir - der kennt seine platten *g
Aber wenn Du was sehen willst - dann gib einfahc mal v/a ein
mit v/a findest du alle various artists

Gruss nky

[commander-x]

php/mysql zu benutzen war auch der grund, erstmal keine xml variante zu benutzen.

allerdings versuche ich mich jetzt an einer offline-version des ganzen und da muss ich u.a. auch mal ohne datenbank auskommen...

[nky]

dann fährst du mit 2004 eindeutig schneller....wobei das eher am player liegt als an der optimierten xml verarbeitung....

man sollte mal versuchen ein mx datei in 2004 zu kompilieren ....vielleicht ist das genausoschnell.....ich denk echt es liegt echt nur am Player...

Gruss nky

[commander-x]

ich habe auch noch nichts mit 2004 gemacht und bleibe erstmal bei flash mx, aber das mit dem player stimmt in der tat, da macht es denke ich mal keinen unterschied, ob mit mx oder mit mx2004 kompiliert.