Tak to ano :-) Moje poznámka rozhodně nebyla generická, týkala se opravdu jen SAXu a jeho implementace.
Genericky však platí, že pokud zpracovávám velké množství dat, vyplatí se zamyslet zda potřebuji vyrábět nové objekty nebo zda to bude jen benchmark garbage collectoru. Samozřejmě ne jako _premature_ optimalization. Kamil Podlešák 2010/9/3 Oto Buchta <ta...@buchtovi.cz>: > Dne 3. září 2010 11:04 Kamil Podlesak <kamil.podle...@gmail.com> napsal(a): >> S čím konkrétně nesouhlasíte? Nějak mi to nedává smysl... > > S generickým tvrzením, že při zpracování obrovských XML je třeba > hlídat OutOfMemory. Mnoho lidí o pull parserech v životě neslyšelo a > proto by ono tvrzení mělo obsahovat klíčovou formulaci "při použití > SAXu", už jenom proto, aby to lidi trklo, že asi existuje technologie > zpracování XML jiná než SAX, u které to nehrozí. > > Ano, mohl jsem volit slova jako "ještě bych doplnil...", ale takto je > to více do očí bijící. Takže nic proti. > >> Samozřejmě, pull parser je v takovémto případě lepší než SAX - však >> také proto pull parsery vůbec existují. >> Ale to neznamená, že se nikdo nepokoušel SAX parser optimalizovat. >> >> Kamil Podlešák >> >> 2010/9/2 Oto Buchta <ta...@buchtovi.cz>: >>> Dne 1. září 2010 15:48 Kamil Podlesak <kamil.podle...@gmail.com> napsal(a): >>>> Ono se to nezdá, ale používání stále jediné datové struktury (místo >>>> vytváření nových) ušetří hodně práce garbage collectoru a u opravdu >>>> obrovských xml to bude znát (dokonce by mohlo dojít OutOfMemoryError). >>> >>> Nesouhlasím. U opravdu velkých XML (řádově stovky MB a více) není >>> konstrukce objektové reprezentace XML vůbec žádoucí a tedy pro tento >>> případ je HashMapa na atributy získávaná pomocí PullParseru ideálním >>> řešením. A dobrý Pull Parser používá pool, takže se akorát přesunou >>> Stringy. Doufám, že takto funguje STAX (JSR 173). Nikdy jsem jiný než >>> Systinetí PullParser nepoužíval - od dob Systinetu jsem nedělal s >>> velkými XML. >>> >>>> Kamil Podlešák >>>> >>>> 2010/9/1 Tomáš Procházka <t.procha...@centrum.cz>: >>>>> Díky za tip. Zajímavé, že to v 99% funguje takto naprosto v pořádku, >>>>> kopírovat všechny atributy do hashmapy pro každý XML element mi příjde >>>>> jako >>>>> zbytečnost, když už to je vše v instanci Attributes :-( >>>>> >>>>> >>>>> --------------------------- Původní zpráva --------------------------- >>>>> Odesilatel: Kamil Podlesak <kamil.podle...@gmail.com> >>>>> Předmět: Divná chyba v SAX parseru? >>>>> Datum: 1. září 2010, 11:25:40 (GMT +0200) >>>>> Přílohy: <none> >>>>> msgid:aanlktim1orq7=mcrkbitxqjgseuxprdncpsbrsc4s...@mail.gmail.com >>>>> >>>>> K> Zdravím, >>>>> >>>>> K> Nejedná se o chybu, v dokumentaci (javadoc k metodě startElement, od >>>>> K> verze 1.5 výše) je napsáno: >>>>> >>>>> K> atts - the attributes attached to the element. If there are no >>>>> K> attributes, it shall be an empty Attributes object. The value of this >>>>> K> object after startElement returns is undefined >>>>> >>>>> K> Ta poslední věta je klíčová: data z těch atributů si musíte "vytahat" >>>>> K> do nějaké vlastní struktury. >>>>> >>>>> K> Kamil Podlešák >>>>> >>>>> K> 2010/9/1 Tomáš Procházka <t.procha...@centrum.cz>: >>>>>>> Zdravím. >>>>> >>>>>>> Setkal se už někdo s tím, že si standardní SAX parser v JDK 1.6 >>>>>>> (konkrétně >>>>>>> mám 1.6.0.18) vymýšlí neexistující hodnota atributů v XML? >>>>> >>>>>>> Konkrétně mám XML, které obsahuje kromě jiného asi 20 000 takovýchto >>>>>>> elementů? >>>>>>> <replace key="...">...</replace> například <replace >>>>>>> key="unsubscribe">http://nekde.cz/neco.html</replace> >>>>> >>>>>>> V SAX handleru, bez jakéhokoliv knihovny, jen v samotné Javě. >>>>> >>>>>>> V handleru pak v metod >>>>> >>>>>>> public void startElement() si pak pouze uložím do třídních proměnných >>>>>>> atributy tagu a nuluju StringBuffer >>>>> >>>>>>> this.value.setLength(0); >>>>>>> this.attributes = attributes; >>>>> >>>>>>> v endElement() pak ukládám do mapy vždy hodnotu atributu key a obsah >>>>>>> celého >>>>>>> elementu, tedy: >>>>> >>>>>>> someMap.put(attributes.getValue("key"), value.toString()); >>>>> >>>>>>> všechno funguje, až na to, že zhruba v 300 případech z těch 20 000 >>>>>>> elementů >>>>>>> se přečte úplně jiný klíč, přípustné hodnoty jsou jen unsubscribe a link >>>>>>> a v >>>>>>> těch 300 případech tam je něco jako " <" >>>>> >>>>>>> Což je samozřejmě nepřípustné >>>>> >>>>> >>>>>>> Zkoušel jsem za >>>>> >>>>>>> this.attributes = attributes; >>>>> >>>>>>> přidat >>>>> >>>>>>> if (attributes.getValue(0) != null && >>>>>>> !"link".equals(attributes.getValue(0)) >>>>>>> && !"unsubscribe".equals(attributes.getValue(0))) { >>>>>>> logger.error("-------- '" + attributes.getValue(0) + "'"); >>>>>>> } >>>>> >>>>>>> abych si zalogoval všechny případy kdy k tomu dojde a přestalo to dělat, >>>>>>> téměř úplně >>>>> >>>>>>> Takové chování VM vůbec nechápu. Kdyby to dělalo jen na jednom stroji, >>>>>>> tak >>>>>>> řeknu, že je něco rozbité na něm. Jenže na ten problém jsme přišli na >>>>>>> Linuxovém serveru a bez problémů jsem ho napodobil i na Windows stroji. >>>>>>> navíc import ještě probíhá jen v jednom vlákně. >>>>> >>>>> >>>>> >>>>>>> Datum: 9:38:09 1. září 2010 >>>>>>> -- >>>>>>> --------------------------------------------------------------------- >>>>>>> Tomáš Procházka >>>>> >>>>> >>>>>>> E-mail: t.procha...@centrum.cz >>>>>>> WWW: http://www.atomsoft.cz >>>>>>> ICQ: 87147320 >>>>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>> ------------------------ Konec původní zprávy ------------------------ >>>>> >>>>> -- >>>>> --------------------------------------------------------------------- >>>>> Tomáš Procházka >>>>> >>>>> >>>>> E-mail: t.procha...@centrum.cz >>>>> WWW: http://www.atomsoft.cz >>>>> ICQ: 87147320 >>>>> --------------------------------------------------------------------- >>>> >>> >>> >>> >>> -- >>> Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com >>> >> > > > > -- > Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com >
