Dotaz: rozumnej XSLT procesor co umí 2.0

[jeleniste]

Potřeboval bysem doporučit rozumnej XSLT procesor, kterej bude umět 2.0, nebo alespoň tu část 2.0, kde jsou regexy. Rozumnej znamená výkonnej a rozumě rychlej, použitelnej i na větší data. Dík Je.

---

---

Odpovědi

[jeleniste]

Saxon

[jeleniste]

Díky.

[jeleniste]

No, ale nebude loudavej, kvůli javě? Ten XALAN 2,0 asi neumí, co?

[Kit]

Však Java je dost rychlá. Zkusil sis tu rychlost změřit?

[jeleniste]

Měřit sem nic nezkoušel, vím jen to, co jsem vygůgloval.

[jekub]

vím jen to, co jsem vygůgloval

tak s tímhle se setkávám čím dál častěji, a to i mimo IT

[jeleniste]

No, za starejch časů bysem musel do knihovny, patlat se s lístečkama a nechat si něco poslat kdoví odkud, čekal bysem měsíc. Dneska se holt gůgluje.

[Kit]

No vidíš, já si takové troufalosti o pomalosti jazyků raději ověřuji. A často vycházejí hodnoty, které jsou v přímém rozporu s obecně uznávaným tvrzením. Jedním z nich třeba je, že Java je pomalá. Je skoro tak rychlá, jako C. Jen spouštění jí trvá trochu déle, protože se musí nastavit prostředí a případně překompilovat bytecode. Proto se ti to na malém objemu dat bude zdát výrazně pomalejší, než v C, ale na velkém objemu dat se to skoro srovná.

[jeleniste]

Hm, znamená to, jestli tomu dobře rozumím, že při přeparsování velkého množství (tisíce) menších souborů - což je můj případ ten rozdíl oproti XSLTPROC, které používám teď docela poznám?

[Filip Jirsák]

Javu můžete spustit jen jednou, jednou zkompilovat XSLT šablonu a pak už jí jen předhazovat jednotlivé soubory. Ale to už bude potřeba napsat si na to 3řádkový program v Javě. S řádkovou utilitou, která je součástí Saxonu, by to sice teoreticky šlo také, ale nevím, jak by se to celé tvářilo na tisíce parametrů v příkazové řádce.

[Šangala]

Pokud to ovšem nejsou větší věci, které lze elegantně řešit v C pointerovou aritmetikou, případně zpracování unsigned int/int64, to už se to v Javě musí asi umět, aby to nekulhalo, i kdoví jestli to lze dohnat… .
Což není obvykle až tak důležité, ale důležité je myslet na to, že když se udělá utilitka a bude se spouštět moc-×, tak C-čkový program bude mít konstantní čas na každou iteraci, u Javy záleží na JRE.
Pokud to bude program, který se spustí jen jednou a zpracuje spoustu iterací, tak může být klidně Java rychlejší, protože se určité typy kódů napíší daleko snadněji efektivní než v C-čku, kde se na to třeba i vykašleš, bo je to moc práce…

[l0gik]

JIT jazyky hlavně uměj optimalizovat del runtime analýzy kódu. Díky tomu můžou bejt i rychlejší, než "statickej" kód v C.

[Kit]

Myslím si, že je to výstižné. Java má prodlevy hlavně při spouštění aplikace, ale potom už běží dost svižně.

[jeleniste]

Prosimtě, existuje způsob, jak z XSL zařídit, aby se mě řetězec projel sedem??

[Kit]

Když máš XSL, nepotřebuješ sed.

[jeleniste]

No, s tou podporou regexpů asi ne (mě se docela líbí ta tokenizace), ale koukam na to jak tele na nový vrata. V podstatě potřebuju jen jednoduchou věc, mám seznam hodnot oddělenejch mezerama (gml) a já z toho potřebuju udělat SQL INSERT s EWKT, protože postgis neumí načíst z gml křivky a kruhy, jen lomený čáry. V EWKT jsou páry souřadnic oddělený čárkou, tj potřebuju přidat čárku do každý sudý mezery. Navíc potřebuju přidat před souřadnice mínus (kvůli změně kvadrantu v sjstk). V pokusných verzích jsem prostě zdrojový xml projel sedem a pak jsem ho až parsoval. To mi ale nepřijde uplně "čisté". Já nejsem teda uplně přesvědčenej, že je dobrý z hlediska výkonu, to dělat přez regexpy (další zavedená, moýná mylná představa?), když by to šlo udělat smyčkou. No já sem v tom xsl a xml uplně novej (pár dní), potřebuju dostat data do databáze a rád bych na to měl nějakej robustní, smysluplnej postup. Když už to dělam.

[Filip Jirsák]

Na to se vám asi bude hodit funkce tokenize().

[jeleniste]

Hm, tak zatim sem nakonec použil toto

[jeleniste]

Můžete napsat jednoduché rozšíření, ze kterého byste ten sed mohl zavolat. Otázka je, zda je to nutné – regulární výrazy jsou silný nástroj.