Re: options.[ch]

[Dirk Herrmann]

On Mon, 1 Oct 2001, Rob Browning wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > Should I commit these changes, or does someone expect major negative
> > performance implications due to the changed performance of the option
> > functions? - Note that reading of option values is not effected if done
> > from the C level.
> 
> Will this affect things like enabling/disabling traps?  If so, then
> I'm wondering about how this will affect the (currently primitive)
> statistical profiler's performance, and the performance of other
> similar tools.

I don't know - how does one enable/disable traps?  If this is done using
the standard option interface then, yes, it will influence performance.  
I have not used the profiler or similar stuff.  If you would like to see
the performance implications of my change, I'd be happy to post it as a
patch to the head of the development branch to you.

However, it is worth noting that the option interface as it is now also
does not provide the best possible performance for frequently changed
options.  If you change an option in some group, for example an option
from the debug group, then all options in that group are searched until
the right one is found.  The ordering of the options in the scm_t_option
array influences how long it takes to find a particular one.  For example,
(debug-enable 'cheap) is executed fastest, while (debug-set!
'show-file-name) takes the longest time.  This is due to the overall
design of the options interface.

For tools that change certain options with such a high frequency that the
performance of the option setting is crucial, we should think of a
possibility to set certain options directly.  It may well be that the
whole options interface, as it is now, is not the best solution anyway,
since one of the motivations for providing the options interface in its
current way was to avoid name space pollution (see the comments at the top
of options.c).  With modules, however, this shouldn't be a major concern.

Best regards
Dirk Herrmann