On 10/11/09, Alexandre Ferrieux <alexandre.ferrieux@[...].com>  wrote:
> 
>  Yes, I feel sympathetic with that last remark, as I follow this
>   strategy all the time (no "debug level", always log, and delete the
>   logs if nothing went wrong)... as long as it doesn't hamper
>   performance. Here the overhead is slight but nonzero, so I'm ready to
>   work a little bit more on optimizing it, if we decide to leave the
>   feature on by default.
> 
>   I believe the measured overhead comes from the ckalloc-ed element
>   arrays of the small lists built to contain argslist at each level; the
>   "backbone" list costs much less, because careful steps are taken to
>   modify it in-place whenever possible.
> 
>   I can see two options to speed this up:
> 
>    (1) grow a flat list instead of a list of lists, inserting integer
>   counts of arguments before each argslist:   {3 foo a b 1 bar 2 baz
>   gnats} and transform it into a true error stack only on  final [info
>   errorstack] request: {{foo a b} bar {baz gnats}}
> 
>    (2) grow a Lisp-like nested linked list based on Tcl_Obj's which are
>   Cons cells (one car + one cdr). This has the advantage of relying
>   exclusively on the Tcl_Obj allocator. On final request, it must also
>   be transformed back into a true Tcl list (2a) , or (2b) at least have
>   a string representation identical to that of the wanted list (just
>   like dicts look like lists on strep examination).
> 
>   If the constraint of landing in the options dict holds, then (2b) is
>   the way to go.
>   Please give me your preference.

Let me rephrase.
The principle is roughly

    lappend errorstack [info level 0]

The current implementation reuses the optimization of in-place
[lappend] so that it doesn't incur extra allocations in routine use.
But [info level 0] is actually a

    Tcl_NewListObj(varFramePtr-> objc,varFramePtr->objv);

which means 2 ckallocs (one for the fixed size List intrep, one for
the elements array).

Question: should I

   (1) leave it as is with the on/off switch, off by default.
       =>  trivial code, slight performance cost, must be switched on.

   (2) optimize it to a ckalloc-free variant (with two alternatives
sketched earlier)
       =>  more complex code, zero performance cost, always on.

Please help me decide. I have no problem implementing either choice, I
just don't want to waste time,

-Alex

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core