* Performance tips when using regular expressions (regexps) in font-locking
@ 2007-11-21 17:00 Nordlöw
2007-11-30 16:42 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Nordlöw @ 2007-11-21 17:00 UTC (permalink / raw)
To: help-gnu-emacs
I have enhanced my cc-mode with extra font-locking for assignments,
function calls, numerical literals, operators and even format strings
to the [sf]?printf-functions. The regular expressions describing these
context are quite complicated and as a result my cc-mode is no longer
as snappy as without my enhancement. Does any have any tips on how to
write regular expressions when performance is crucial? For example
should I use [:space:] instead of [ \t]? Should I post the code
aswell?
Thanks in advance,
Nordlöw
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Performance tips when using regular expressions (regexps) in font-locking
2007-11-21 17:00 Performance tips when using regular expressions (regexps) in font-locking Nordlöw
@ 2007-11-30 16:42 ` Stefan Monnier
2007-12-16 18:28 ` David Combs
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2007-11-30 16:42 UTC (permalink / raw)
To: help-gnu-emacs
> I have enhanced my cc-mode with extra font-locking for assignments,
> function calls, numerical literals, operators and even format strings
> to the [sf]?printf-functions. The regular expressions describing these
> context are quite complicated and as a result my cc-mode is no longer
> as snappy as without my enhancement. Does any have any tips on how to
> write regular expressions when performance is crucial? For example
> should I use [:space:] instead of [ \t]? Should I post the coden
> aswell?
I believe inmost cases micro-optimization such as choosing between
[[:space:]] and [ \t] will make no noticeable difference.
But you should pay attention to * and + operators, especially when
nested or when adjacent and make sure that there is no redundancy: there
should ideally be only one way for the regexp to match a given piece
of text.
E.g. avoid [ab]*a*
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Performance tips when using regular expressions (regexps) in font-locking
2007-11-30 16:42 ` Stefan Monnier
@ 2007-12-16 18:28 ` David Combs
0 siblings, 0 replies; 3+ messages in thread
From: David Combs @ 2007-12-16 18:28 UTC (permalink / raw)
To: help-gnu-emacs
In article <jwveje71yc7.fsf-monnier+gnu.emacs.help@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I have enhanced my cc-mode with extra font-locking for assignments,
>> function calls, numerical literals, operators and even format strings
>> to the [sf]?printf-functions. The regular expressions describing these
>> context are quite complicated and as a result my cc-mode is no longer
>> as snappy as without my enhancement. Does any have any tips on how to
>> write regular expressions when performance is crucial? For example
>> should I use [:space:] instead of [ \t]? Should I post the coden
>> aswell?
>
>I believe inmost cases micro-optimization such as choosing between
>[[:space:]] and [ \t] will make no noticeable difference.
>But you should pay attention to * and + operators, especially when
>nested or when adjacent and make sure that there is no redundancy: there
>should ideally be only one way for the regexp to match a given piece
>of text.
>
>E.g. avoid [ab]*a*
>
>
> Stefan
Friedel's "Regular Expressions" book (O'Reilly) (cheaper from Bookpool.com),
the *bible* on regexps (*hundreds* of pages long) has an entire chapter
devoted to optimizing your regexps. Essential reading.
(You may *think* you know something about regexps -- read that book,
and you'll know different! :-)
David
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-12-16 18:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-21 17:00 Performance tips when using regular expressions (regexps) in font-locking Nordlöw
2007-11-30 16:42 ` Stefan Monnier
2007-12-16 18:28 ` David Combs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).