Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#480 Shrink the .exe size

closed-fixed
None
4
2006-08-10
2006-07-28
afredd
No

By converting the 24 calls of:

Tcl_Panic("<function> called with shared object");

in the core, into a (new) function call of

TclSharedObjPanic("<function>");

...where TclSharedObjPanic() constructs the previous
message before calling Tcl_Panic() then
the static .exe shrinks by about 4K (from 770048
to 765952). This is more than i'd expected, so
compilers other than VS6 may give less impressive
savings.

Attached patch includes the trivial changes to

tclBinary.c
tclDictObj.c
tclInt.h
tclListObj.c
tclObj.c
tclStringObj.c

Discussion

  • afredd
    afredd
    2006-07-28

    Logged In: YES
    user_id=1386588

    To go with the previous changes, here's a patch that
    removes the need for the "::tcl::mathfunc::" prefix
    on all math function name static strings in tclBasic.c.
    For me this shrinks tclBasic.obj from 80963 to 79965,
    a saving of 998bytes.

     
  • afredd
    afredd
    2006-07-28

    Patch for tclBasic.c

     
    Attachments
  • afredd
    afredd
    2006-07-28

    Logged In: YES
    user_id=1386588

    ...and one for tclClock.c that shrinks tclClock.obj
    from 23,417 to 23,201 by condensing the clock command
    initialisation code.

     
  • afredd
    afredd
    2006-07-28

    Patch for tclClock.c

     
    Attachments
  • Don Porter
    Don Porter
    2006-07-31

    • assigned_to: nobody --> dkf
     
    • priority: 5 --> 2
    • status: open --> open-later
     
  • Logged In: YES
    user_id=79902

    Putting this on the back-burner for now; better to do this
    sort of thing during (towards the end of?) the beta cycle.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2006-08-03

    • priority: 2 --> 4
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2006-08-03

    Logged In: YES
    user_id=72656

    I'm interested to know if the same effect can be had by just
    using:

    Tcl_Panic("%s called with shared object", <function>);

    as the string would remain the same, and no new function is
    needed (Tcl_Panic already handles varargs). If so, that
    would be a trivially easy to add in patch.

     
  • afredd
    afredd
    2006-08-04

    Logged In: YES
    user_id=1386588

    > I'm interested to know if the same effect can be had by
    > just using:
    >
    > Tcl_Panic("%s called with shared object", <function>);

    Good idea... yes, this gives the same 4K file
    size reduction as with using a TclSharedObjPanic().

    Also, spotted in tclExecute.c:

    ~1043: Tcl_Panic("shared object passed to TclIncrObj")

    which could be reworded to match the others.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2006-08-04

    Logged In: YES
    user_id=72656

    can you (afredd) please provide the alternate patch? thx

     
  • afredd
    afredd
    2006-08-07

    As per Jeff's request

     
  • afredd
    afredd
    2006-08-07

    Logged In: YES
    user_id=1386588

    > can you (afredd) please provide the alternate patch? thx

    Sure - here it is.

    I've also added in the reworded Tcl_Panic for TclIncrObj.

    Note, while i haven't changed them there are 2 possible
    typos in the (original) panic messages. (1) The panic
    at ~1323 of tclListObj.c says "Tcl_ListObjSetElement"
    but is really in TclListObjSetElement (no underscore).
    (2) Similarly, at ~344 in tclBinary.c the panic in the
    function Tcl_SetByteArrayLength says Tcl_SetObjLength.

     
  • afredd
    afredd
    2006-08-07

    Logged In: YES
    user_id=1386588

    Another few bytes can be saved by removing the
    redundant first "if (objc < 1)" test in Tcl_UnsetObjCmd.
    ie. are there a negative number of command arguments.
    Looks like a harmless mistranslation of the code for the
    old behaviour when [unset] was an error.

    Anyways saves a few bytes (257) from the tclVar.obj,
    and possibly from the .exe too.

     
  • afredd
    afredd
    2006-08-07

     
    Attachments
  • Logged In: YES
    user_id=79902

    Applied fixes suggested. Will not backport.

     
    • status: open-later --> closed-fixed