Re: timezone.el patterns in emacs 19.34

[Ken Raeburn <raeburn@cygnus.com>]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > I noticed some time ago that timezone-parse-date took up a large
> > portion of the time of building a summary buffer in Gnus.
> How large a portion?  20%, 50%?  Looking at timezone.el, it looks like

I don't remember for sure; the timing I did was some time ago.  In my
recent checks (mostly to verify the names of the routines before I
started looking at them) I interrupted the "generating summary" phase,
with debug-on-quit set, and that's where it usually wound up according
to the backtrace.

> it should be written in C.  It's not that hard to write, and the
> speedup would measure by hundreds (all those regexps would become
> unnecessary).

I'm not so sure about converting it to straight C; I could imagine
wanting to change the supported format list someday, and wanting to do
so easily -- i.e., without recompiling emacs.  (In fact, the ISO
format Francois Pinard just recommended using may require changes to
get the time zone right.)  Besides, I think you'd probably wind up
doing the regexp bit anyways, just at the C level.  These patterns
don't have to match the *entire* string, just some substring.

And if you do one regexp match, well, that doesn't seem much better
than what you'd do in what appears to be the common case under Gnus,
if you use the reordering I suggested.

Now, if we can ignore or work around that substring issue (not a
trivial issue, Gnus isn't the only user of that code), and require a
match against the whole string, then using getdate.y might be a win.
I understand it's supposed to be pretty comprehensive.

Ken