2010-09-29 10 views
10

in qualche modo legati a: libxml2 from javaperché l'analisi del sax è più rapida di quella del parsing? e come funziona stax?

sì, questa domanda è piuttosto prolisso - mi dispiace. Ho mantenuto è denso come mi sentivo possibile. Ho messo in evidenza le domande per rendere più facile sbirciare prima di leggere il tutto.

Perché l'analisi del sax è più rapida di quella del parsing? L'unica cosa che posso inventare è che w/sax stai probabilmente ignorando la maggior parte dei dati in arrivo, e quindi non sprecare tempo a elaborare parti dell'XML che non ti interessa. IOW: dopo aver analizzato w/SAX, non è possibile ricreare l'input originale. Se hai scritto il tuo parser SAX in modo che corrisponda a ogni singolo nodo xml (e possa così ricreare l'originale), allora non sarebbe più veloce di DOM?

Il motivo per cui sto chiedendo è che sto cercando di analizzare i documenti xml più rapidamente. Devo accedere all'intero albero xml DOPO l'analisi. Sto scrivendo una piattaforma per i servizi di terze parti da collegare, quindi non posso prevedere quali parti del documento xml saranno necessarie e quali parti no. Non conosco nemmeno la struttura del documento in arrivo. Questo è il motivo per cui non posso usare jaxb o sax. L'ingombro della memoria non è un problema per me perché i documenti xml sono piccoli e ho solo bisogno di 1 in memoria alla volta. È il tempo necessario per analizzare questo documento xml relativamente piccolo che mi sta uccidendo. Non ho usato stax prima, ma forse ho bisogno di indagare ulteriormente perché potrebbe essere la via di mezzo? Se ho capito bene, stax mantiene la struttura xml originale ed elabora le parti che chiedo a richiesta? In questo modo, il tempo di analisi originale potrebbe essere veloce, ma ogni volta che chiedo di attraversare una parte dell'albero che non ha ancora attraversato, è in quel momento che avviene l'elaborazione?

Se si fornisce un collegamento che risponde alla maggior parte delle domande, accetterò la risposta (non è necessario rispondere direttamente alle mie domande se hanno già risposto altrove).

aggiornamento: l'ho riscritto in sax e analizza i documenti su avg 2,1 ms. Questo è un miglioramento (16% più veloce) sopra i 2,5 ms che dom stava prendendo, tuttavia non è la grandezza che io (ed altri) avrei immaginato

Grazie

+0

Direi che la domanda di quale è più veloce è irrilevante per i propri scopi, perché è necessario effettuare query arbitrarie contro l'albero. Ciò significa che devi costruire una rappresentazione dell'albero e avere un modo per creare query su di esso. Quindi o usi DOM/XPath, o scrivi i tuoi equivalenti. – Anon

+0

Sospetto, tuttavia, che il tuo vero problema non sia SAX vs DOM in sé, ma in che modo il tuo sistema è configurato e/o in che modo stai accedendo ai dati. In realtà non dovrebbe richiedere molto tempo per analizzare un documento "piccolo" usando DOM (o uno degli equivalenti del DOM). Hai quantificato la differenza (che stai vedendo) tra SAX e DOM? – Anon

+0

Ho quantificato l'approccio DOM. piccoli (circa 300k) documenti xml. L'implementazione corrente utilizza xerces-j e richiede circa 2,5 ms per documento xml su una macchina a 1,5 GHz. per quantificare il sax dipende in qualche modo dalla quantità di xml che si sceglie di conservare e da ciò che si fa con esso. hai ragione - non penso che il sax funzionerà per me - la domanda era più per curiosità. – andersonbd1

risposta

14

Supponendo che non fanno altro che analizzare il documento, la classifica dei diversi standard parser è la seguente:

1. StAX è il più veloce

  • L'evento è segnalato per voi

2. SAX è accanto

  • Si fa tutto StAX fa più il contenuto viene realizzato automaticamente (nome dell'elemento, dello spazio dei nomi, attributi, ...)

3. DOM è ultima

  • Fa tutto SAX fa e presenta le informazioni come un'istanza di Nodo.

vostro caso d'uso

  • Se è necessario mantenere tutti i XML, DOM è la rappresentazione standard. Si integra perfettamente con le trasformazioni XSLT (javax.xml.transform), XPath (javax.xml.xpath) e API di convalida dello schema (javax.xml.validation). Tuttavia, se la prestazione è la chiave, potresti essere in grado di costruire la tua struttura ad albero usando StAX più velocemente di quanto un parser DOM possa creare un DOM.
+0

Um, cosa pensi che succeda quando "L'evento ti viene riferito" contro "il contenuto viene realizzato automaticamente"? – Anon

+4

StAX segnalerà che l'elemento è stato avviato, se non si richiede mai il nome dell'elemento o l'URI, allora i dati non devono mai essere realizzati come oggetti String. D'altra parte un parser SAX realizzerà i dati come oggetti String come parte dell'evento. –

+0

Forse. E se mi dici che hai guardato gli interni di StaX e che è costruito attorno a una macchina statale basata sui personaggi, ti crederò. Tuttavia, mi aspetto che generi token internamente, anche se non li chiedi mai. – Anon

10

DOM analisi richiede di caricare l'intero documento in memoria e quindi attraversare un albero per trovare le informazioni desiderate.

SAX richiede solo la quantità di memoria necessaria per eseguire l'IO di base ed è possibile estrarre le informazioni necessarie durante la lettura del documento. Poiché SAX è orientato al flusso, è possibile anche elaborare un file che viene ancora scritto da un altro processo.

+0

sì, lo capisco. La mia domanda era "perché l'analisi del sax è più veloce?" non "qual è la differenza tra sax e dom?" – andersonbd1

+0

@ Stargazer712 - la risposta di mikerobi non ha risolto la mia domanda. Dubito che abbia letto anche la domanda. È una risposta automatica a qualsiasi domanda dom/sax. Ho una mente aperta se qualcuno ci mettesse il tempo per dare una risposta ponderata. – andersonbd1

+2

@ andersonbd1, ho preparato la tua domanda, mi dispiace che tu non abbia capito la mia risposta. Per me è abbastanza ovvio che un processo che richiede più memoria e non ti dà accesso ai dati finché non viene completamente analizzato sarà più lento di un processo che richiede pochissima memoria e ti consente di accedere ai dati quasi alla velocità può essere letto – mikerobi

10

SAX è più veloce perché i parser DOM utilizzano spesso un parser SAX per analizzare internamente un documento, quindi eseguono il lavoro extra di creazione e manipolazione di oggetti per rappresentare ogni singolo nodo, anche se l'applicazione non gli interessa.

Un'applicazione che utilizza direttamente SAX è in grado di utilizzare l'insieme di informazioni in modo più efficiente rispetto a un "parser" DOM.

StAX è un mezzo felice in cui un'applicazione ottiene un'API più conveniente rispetto all'approccio basato sugli eventi di SAX, ma non risente dell'inefficienza della creazione di un DOM completo.

1

SAX è più veloce di DOM (di solito si avverte durante la lettura di un documento XML di grandi dimensioni) perché SAX fornisce informazioni come una sequenza di eventi (generalmente accessibili tramite un gestore) mentre DOM crea Nodi e gestisce la struttura di creazione del nodo fino a quando non viene creato un albero DOM completamente creato (come rappresentato nel documento XML).

Per file relativamente piccoli, non si avverte l'effetto (ad eccezione del fatto che probabilmente l'elaborazione aggiuntiva viene eseguita dal DOM per creare l'elemento nodo e/o l'elenco dei nodi).

Non posso davvero commentare StAX poiché non ho mai giocato con esso.

Problemi correlati