[Tcl-bugs] [ tcl-Patches-1246897 ] Minor optimsations for Tcl_DStringAppend usage.

[SourceForge.net <no...@so...>]

Patches item #1246897, was opened at 2005-07-28 12:11
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=1246897&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Don Porter (dgp)
Summary: Minor optimsations for Tcl_DStringAppend usage.

Initial Comment:
Minor optimisation: there are a few calls to 
Tcl_DStringAppend with fixed strings, but give a length 
of -1. Replacing the -1 with the actual length (as is done 
in other places) would save a strlen.
eg.


tclConfig.c:141:    Tcl_DStringAppend 
(&cmdName, "::",          -1);
tclConfig.c:161:    Tcl_DStringAppend 
(&cmdName, "::pkgconfig", -1);
tclInterp.c:433:    Tcl_DStringAppend(&script, "lsearch -
exact", -1);
tclInterp.c:437:    Tcl_DStringAppend(&script, " [file join 
[info library] encoding]", -1);
tclInterp.c:450:    Tcl_DStringAppend(&script, "file join 
[info library] encoding", -1);
tclUtil.c:1856:	Tcl_DStringAppend(dsPtr, " {", -1);
tclUtil.c:1858:	Tcl_DStringAppend(dsPtr, "{", -1);
tclUtil.c:1885:    Tcl_DStringAppend(dsPtr, "}", -1);

There are also some where the string being copied is a 
Tcl_DString, so we could use the corresponding 
Tcl_DStringLength instead of -1; again saving a strlen.

eg.

tclLoad.c:349:	Tcl_DStringAppend(&initName, 
Tcl_DStringValue(&pkgName), -1);
tclLoad.c:351:	Tcl_DStringAppend
(&safeInitName, Tcl_DStringValue(&pkgName), -1);
tclLoad.c:353:        Tcl_DStringAppend(&unloadName, 
Tcl_DStringValue(&pkgName), -1);
tclLoad.c:355:        Tcl_DStringAppend
(&safeUnloadName, Tcl_DStringValue(&pkgName), -1);
tclNamesp.c:823:	Tcl_DStringAppend(&buffer1, 
Tcl_DStringValue(&buffer2), -1);
tclNamesp.c:826:	Tcl_DStringAppend(&buffer2, 
Tcl_DStringValue(&buffer1), -1);

(which makes me wonder if the Right Thing is done if 
any of the above contain embedded NULs in them, as 
the strlen will give the 'incorrect' length.).


Final point, wouldn't the copy loop in Tcl_DStringAppend 
be quicker as a memcpy and not as a character by 
character copy in the for loop. I've no empirical evidence, 
just the (perhaps incorrect!) assumption that the C 
library's memcpy is quicker than the corresponding for 
loop. 

Cheers!

----------------------------------------------------------------------

>Comment By: Don Porter (dgp)
Date: 2005-07-28 18:04

Message:
Logged In: YES 
user_id=80530


The docs aren't explicit about it
(perhaps because they are so old),
but I don't believe the Tcl_DString*
routines were ever intended to
support embedded NUL bytes within
the dynamic strings.

The comment on the "length" field
of the Tcl_DString struct (in tcl.h)
reads:

  Number of non-NULL characters in the string

That said, it's clear that callers of
Tcl_DStringAppend() and
Tcl_DStringSetLength() could leave
NUL bytes within the "length" of the
string.

Wise or not, the Tcl_DString* routines
are fairly low level and have a long
history of exposing that capability.
If it gets too troubling, just make use
of Tcl_Obj's for your dynamically
sized string values.


----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2005-07-28 17:32

Message:
Logged In: YES 
user_id=80530


there's no patch here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310894&aid=1246897&group_id=10894