Re: ANNOUNCE: The Simple Development Library version 1.0

yahalom wrote:
> there is not mention of performance hit when using these packages. do
> you have such data?

Loading SimpleDevLib packages and programs is slower than not using
SimpleDevLib, of course. Apart from the obvious need of loading
SimpleDevLib itself (once per interpreter), SimpleDevLib needs to parse
the declarations and performs and exahustive consistency check (for
example, it checks that a package defines command exclusively within
its namespaces or the namespaces owned by its direct required
packages). This is *very* convenient for development, but not so for
deployment; thus, one of my top priority features for a next version is
allowing the user the generation of pre-parsed, pre-checked packages.

Now, in run-time the performance hit is minimum, in general. From the
top of my head I can think on three performance hot stops (in order
of increasing tempearature):

1) Subcommand invocation: subcommand "foo bar" is implemented as a
'base' procedure {foo} which dispatches the call to another procedure
named {foo bar}. This dispatching takes some microseconds. You can
call the {foo bar} procedure directly, but that's a kludge.

2) Variable/attribute type monitoring: as you may expect, type
monitoring might be expensive. This is implemented as a trace on
the variable which gets triggered whenever its value changes. Then,
conformace against the variable type is evaluated.

3) Procedure/method invocation with argument run-time type
checking and/or flags in the argument list: this is a potentially
*significant* performance hog, and so is well documented at
http://simpledevlib.sourceforge.net/SimpleProc.html#section3.1
(first bullet).

The good news is that if argument run-time type checking is disabled
and the argument list has no flags, then SimpleDevLib procedures/
methods are fully equivalent to regular Tcl procedures/[incr Tcl]
methods at all levels, including invocation time.

Now, if argument run-time type checking is enabled we obviously have
something similar to 2) above, although without traces, and applied
to all the procedure/method arguments.

The feature to keep an eye on should performance be an issue is
procedure/method flags, because it might not be obvious.

By default SimpleDevLib handles the flags in the argument list,
and this requires a run-time parsing of the arguments, which is slow.
Now, you can parse the flags yourself by declaring the procedure/
method with -parseflags false, and so the procedure/method is
again converted in a regular Tcl/[incr Tcl] one (the actual procedure/
method which gets created has the first flag and following arguments
replaced by the args special argument).

In my laptop a procedure with two flags, followed by another two
non-flag arguments (all of them integers) takes 88 microseconds per
call, or 2 with -parseflags false, or 216 with argument run-time type
enabled.

Juan Carlos---
Received on Thu Sep 29 14:24:09 2005