This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> > 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.