Re: Slow regexps.

[Jim Blandy <jimb@red-bean.com>]

>  > I just looked over the regexp code (posix-regexp.c) & noticed the
>  > following:
>  > 
>  > 1. It seems the SCM_* macros often expand to rather complicated
>  >    expressions.  Consider SCM_ROCHARS(str) in regex-posix.c.  You have
>  >    a test, posibly an addition & a few indirections.  In
>  >    scm_regexp_exec, there are lots of them used, some of which are
>  >    used over & over again.
>  > 2. The return from regexec is packaged up as a vector (malloccing the
>  >    vector, repeated use of SCM_MAKINUM & SCM_VELTS, etc) then the
>  >    original space used is freed.
>  > 
>  > Wouldn't it help performance in general if:
>  > 
>  > 1. Repeated usages of these things were converted to variable
>  >    assignments followed by repeated accesses of the variable instead,
>  >    and
>  > 2. In scm_regexp_exec in particular, wouldn't it help performance to
>  >    package up the return from regexec as an opaque type with accessors
>  >    for the components so that the vector doesn't have to be built each
>  >    time?
> 
> I also meant to ask if anyone has profiled make-regexp & regexp-exec
> to see if the above makes a measurable difference, or if the bulk of
> the time is spent in the called rtns.

No, nobody has done the profiling.  Not all the macros are as bad as
SCM_ROCHARS; SCM_MAKINUM is just a shift and an add.  SCM_VELTS is
effectively an add and a memory reference.  So I'm not sure that those
two macros are terribly costly.

Using an opaque type to let Scheme manipulate the return value from
scm_regexp_exec might save some time, but opaque types are not really
free --- they create a learning requirement that simply using the
obvious structures does not, they require a new set of primitives,
which had better be complete and convenient, etc.

I'd want to see some profiling results before I accepted a change like
this.