2012-08-01 16 views
5

Sto provando a creare una specie di strumento lint per C/AL programming language. Quindi in pratica ho bisogno di eseguire la sintassi e l'analisi lessicale sul codice sorgente. Ho pianificato di scrivere parser da zero, ma poi ho scoperto che ci sono molti strumenti che aiutano a generare automaticamente questi parser.Chi è più veloce: PEG o GLR?

Ho bisogno di prestazioni, dal momento che il controllo di 20 megabyte di codice in un unico pezzo è lo scenario normale, e ho bisogno che lo strumento sia estensibile da regole personalizzate. Così ho deciso di andare con JavaScript.

Finora ho trovato due generatori che posso utilizzare Jison e PEG.js.

Quali di questi mi danno più prestazioni di analisi? Forse non confrontando le librerie, ma gli algoritmi?

Quale è migliore per le mie esigenze (parsing linguaggio di programmazione generico)?

UPDATE: ho trovato simile Q & Come:

risposta

7

In generale si otterrebbe prestazioni molto buone analisi da un parser shift-ridurre come quello che Jison implementa. Forse è un po 'old-school, ma può funzionare con requisiti di memoria molto stretti e in un tempo lineare.

PEG produce un diverso tipo di parser che è forse più capace, ma richiederebbe più memoria per produrre lo stesso risultato. Cioè PEG richiederà una quantità di memoria proporzionale all'input, mentre un parser LALR lo farà in molto meno spazio (alcune tabelle e una piccola pila).

+0

Grazie! E per quanto riguarda il confronto delle prestazioni? – shytikov

+0

Se le restrizioni che verranno applicate alla grammatica da un parser LR come GLR o LALR (GLR utilizza solo un po 'di memoria in più, ed è un po' più lento) allora è probabile che LR sarà un parser più veloce. Il parser richiede più tempo per generare, dal momento che ha bisogno di calcolare le sue tabelle. Ma nel caso generale i parser LR sono macchine molto efficienti. – Dervall

+0

Nessuno, a parte il tizio che usa il generatore di parser, si preoccupa di quanto tempo impiega il parser generator per funzionare. Anche a lui non importa molto; i grandi parser sono generati in secondi, almeno per i generatori di parser LALR e la maggior parte degli altri che conosco. –

5

"Ho bisogno di prestazioni (per 20 Mb) ... quindi ho deciso Javascript". Questi sono contraddittori.

Gli analizzatori di discesa ricorsivi codificati con cura possono essere abbastanza veloci, ma è necessario scrivere molto codice. Generalmente, i parser LALR (1) (generati da Bison da una grammatica ecc.) Sono abbastanza veloci e facili da codificare. (Ci sono documenti tecnici che mostrano come compilare i parser LALR direttamente sul codice macchina, questi parser sono incredibilmente veloci ma è necessario implementare un sacco di macchinari personalizzati per crearne uno).

Se si desidera eseguire il parsing di un rendimento elevato con una quantità minima di sudore, è necessario considerare LRStar. (Conosco e rispetto molto l'autore ma per il resto non ho nulla da fare). Questo produce parser LALR molto veloci . Lato negativo: devi rendere la tua grammatica LALR compatibile. Dovrai estendere le tue "regole" nello stesso modo in cui tu, , estendi qualsiasi altro programma C: scrivendo codice C. Questo non sembra molto peggio rispetto alla scrittura di JavaScript IMHO, ma probabilmente le regole verranno eseguite molto più velocemente e alla scala che state considerando ciò sarà importante.

L'analisi GLR è necessariamente più lenta rispetto a LALR perché ha più contabilità da fare. Ma questo è solo un fattore costante. Può essere significativo (ad es. 100x) su un motore di prestazioni alto come LRStar. Potrebbe valere la pena, perché è molto più facile sterilizzare la grammatica e una grammatica meno complessa probabilmente renderà più semplice la scrittura di regole personalizzate.Se hai veramente 1 file MSLOC, questi parser preferiranno la velocità media nel migliore dei casi.

PEG è fondamentalmente un backtracking. Deve provare le cose e tornare indietro quando non funzionano. Devono essere più lenti dei parser LALR di almeno la quantità di backtracking che fanno. Hai anche il problema di modellatura della grammatica.

Quello che scoprirete, però, è che l'analisi semplicemente non è sufficiente se volete fare qualcosa di leggermente più sofisticato. In tal caso, non si desidera ottimizzare l'analisi; si desidera ottimizzare l'infrastruttura per l'analisi del programma. Vedi il mio articolo su Life After Parsing per un'altra alternativa.

+0

Grazie! Ho detto che voglio avere regole personalizzate in 'lint', quindi ho assolutamente bisogno di linguaggio di scripting e JavaScript (implementazione V8 node.js) sembra essere più veloce di python, ruby ​​... – shytikov

+0

Non penso che tu abbia capito il mio punto su "Life After Parsing". Sembra che tu abbia corretto la scelta di un linguaggio delle regole su JavaScript, dove fondamentalmente hai un'infrastruttura zero per supportare le tue attività di analisi. In questo modo ottieni il vantaggio di una lingua ampiamente disponibile in cui codificare le tue regole e nessun supporto a cui attingere tali regole. Sono pessimista sul tuo vero successo, a meno che le tue regole non siano fondamentalmente banali ... allora qual è il punto? –

+0

Sto leggendo "Life After Parsing". È lungo e io sono impaziente. Scusate. Guardo JS a causa del fatto che ci sono alcuni strumenti 'lint' con il codice sorgente disponibile su ciò che è stato scritto su JavaScript. Spero che mi aiuti Ma hai ragione. Il compito è enorme ... – shytikov

1

Finora ho trovato due generatori che posso utilizzare Jison e PEG.js. Quali di questi mi danno più prestazioni di analisi?

Secondo il punto di riferimento JavaScript Parser Biblioteche ho creato Sembra che PEG.js è più veloce (almeno su Chrome/V8).

È possibile eseguire online qui: http://sap.github.io/chevrotain/performance/

Si noti che questo benchmark utilizza la grammatica molto semplice JSON per confrontare le prestazioni delle librerie di parsing non una più grande e più complesso linguaggio di programmazione grammatica.

Problemi correlati