On Tue, Aug 26, 2008 at 09:46:22PM +0000, David Lutterkort wrote: > On Tue, 2008-08-26 at 22:01 +0100, Daniel P. Berrange wrote: > > > While I can see why it is useful to gather these entries logically, it's not > > > very optimised for the parser. Eventually, all this will be compiled into a > > > huge regexp, so it's more efficient to regroup entries by type and feed the > > > functions with regexps instead of strings, like > > > > Is performance really that much of a problem ? The libvirt config file > > only has 20 or so different settings, and while we'll add more I can't > > see it getting very much larger. Changing these settings is also not > > something that would be done on a frequent basis / performance critical > > path. I find it more readable to group them by functional area unless > > there is a serious real world performance issue. > > We've seen some cases where it made a _dramatic_ difference. But if it's > fast enough now, I wouldn't worry about it - just keep that in mind when > either running augparse or augtool on it becomes unbearably slow. Out of interest, do you ever hit the 16 bit limit in the size of compiled regexps? The "bytecode" used to represent compiled GNU regexps has (or perhaps had) a 16 bit limit in the jump offsets, which I hit a few years back. Had to switch to using a flex-compiled pattern matcher in the end. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list