Re: timezone.el patterns in emacs 19.34

[Hrvoje Niksic <hniksic@srce.hr>]

Ken Raeburn <raeburn@cygnus.com> writes:

> Okay, so how would you get around the requirement of matching a
> substring, without using regexps?

Simply make as many routines as there are formats.  For example, if
the format is

   Wkd, blah blah

then I search for week days, if I find them, look for `,', etc.  It's
tedious, but I can guarantee that it would be *much* faster than the
current, Lisp code.

> If you can do it, and get much better performance than we've got now
> with the lisp code, great.  But as I just indicated in other mail,
> my trivial little patch already addresses the performance issue to
> some degree.  So you'll have to do even better. :-)

I certainly won't do it before I get the exact numbers of how much
time is spent in timezone.el, before and after your patch.  It is too
much work to speed up Summary buffer building by 5% or so.

> And, by the way, if you do go ahead with this, I'd suggest returning
> numbers instead of strings when practical.  They can be turned into
> strings easily enough in lisp, and the gnus-dd-mmm usage just converts
> them back to numbers and discards the strings, which means more
> needless garbage to collect.  (Don't underestimate the cost of garbage
> collection.  I've managed to speed up some code by tweaking it to
> allocate less short-term heap storage.)

Yup.

> > NO!  I hate getdate.y.  First, because of the `.y' thingie. :-)
> 
> Aside from the substring issue, I think a parser would be well suited
> to this task.  I see two advantages to it:
>  * Tokenizes first, then looks for patterns in the tokens; this means
>    any backtracking doesn't have to re-process every character.
>  * Yacc sets up a FSM for matching multiple sequences in parallel (as
>    do the more sophisticated regexp matchers), so if a match is going
>    to be made, it'll be made in one pass; the hairy work is done at
>    build time.

But it's huge, and we don't need all that cruft.  In a C
implementation of timezone.el, it would make little difference whether
the parser is "intelligent" or not.

> > Then, there are copyright problems with it.
> 
> No, there aren't.

Yes, there are.  The public domain code is not to be introduced in
important parts of Emacs, as it is compromisable.

> > And, I'd like to have a fast routine that matches those 7 or so
> > format strings.
> 
> Yes, that's the problem I see with it -- it'll handle more than we
> want.

`getdate.y' would handle even more.

> A date header saying "+23hours" is bogus, and should be treated
> as such.  Though if getdate.y matches more "real" date formats than
> timezone-parse-date, I don't think it would be a bad idea to support
> them as well, since this is timezone-parse-date we're talking about,
> and not gnus-parse-conforming-date-header.

If I ever rewrite `timezone-parse-date', it will recognize the dates
it recognizes now.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Good pings come in small packets.