1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

TCC Statup times

Discussion in 'Support' started by Steve Fabian, Mar 24, 2010.

  1. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    I am interested in how TCC starting performance is affected by the absence
    or presence of plug-ins and their location (i.e., the absence or existence
    of a PLUGINS subdirectory). Assume for this inquiry that any already loaded
    DLL is in physical, internal memory, and not paged out (else all kinds of
    issues not related to TCC come into play).

    Case 1
    ------
    TCC is started from the desktop or the quick launch bar. Plug-ins are
    autoloaded from the PLUGINS subdirectory. Is this faster if another
    concurrent TCC session has already loaded the plug-ins?

    Case 2
    ------
    TCC is started as a pipe from another TCC instance, which has already loaded
    the plug-ins. The new instance does not utilize any plug-ins. Does the pipe
    start faster if there is no PLUGINS subdirectory than if there is?

    If in either of the above cases there is a difference,
    --
    Steve
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,059
    Likes Received:
    30
    On Wed, 24 Mar 2010 11:33:30 -0400, Steve Fábián <> wrote:

    |I am interested in how TCC starting performance is affected by the absence
    |or presence of plug-ins and their location (i.e., the absence or existence
    |of a PLUGINS subdirectory). Assume for this inquiry that any already loaded
    |DLL is in physical, internal memory, and not paged out (else all kinds of
    |issues not related to TCC come into play).

    I watch TCC's startup time pretty closely and I learned a long time ago that
    plugins don't have much effect (so I don't pay attention to them any more).
    Here's a (reproducible) comparison between loading eight plugins (all mine) and
    loading none.

    v:\> timer & for /l %i in (1,1,10) "%comspec" /c & timer
    Timer 1 on: 11:47:20
    Timer 1 off: 11:47:21 Elapsed: 0:00:00.63

    v:\> timer & for /l %i in (1,1,10) "%comspec" /c /ip & timer
    Timer 1 on: 11:47:23
    Timer 1 off: 11:47:23 Elapsed: 0:00:00.63

    I suppose a plugin **could** have an impact on startup time if it did something
    time-consuming in DllMain() or InitializePlugin(). But I, and others, I
    suppose, are careful to avoid that.
    --
    - Vince
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,059
    Likes Received:
    30
    On Wed, 24 Mar 2010 11:33:30 -0400, Steve Fábián <> wrote:

    |I am interested in how TCC starting performance is affected by the absence
    |or presence of plug-ins and their location (i.e., the absence or existence
    |of a PLUGINS subdirectory). Assume for this inquiry that any already loaded
    |DLL is in physical, internal memory, and not paged out (else all kinds of
    |issues not related to TCC come into play).

    Maybe this comes closer to answering your questions ... a test like the one I
    just posted, but using CMD (so plugin dlls are not in memory). Results are in
    milliseconds (and reproducible). A difference is observed.

    marktime /q & echo off & (for /l %i in (1,1,10) do d:\tc11\tcc.exe /c) &
    marktime

    461.6429

    marktime /q & echo off & (for /l %i in (1,1,10) do d:\tc11\tcc.exe /c /ip) &
    marktime

    412.2755
    --
    - Vince
     
  4. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    I think it will very difficult to detect Vince.
    People forget that speed of execution is primarily

    (i) any file IO that needs to occur
    (ii) memory allocation/deallocation
    (iii) superior algorithms (execution of code counts here)

    Those DLL calls will be dwarfed by the cost of finding and loading the plugin (the file IO). After that, if it is in some cache (that is if Windows has to reload), you are not going to notice. Steve's original request boils down to whether the plugin DLLs are shared or side-by-side DLLs.

    Stephen Howe
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---Quote (Originally by vefatica)---
    || I watch TCC's startup time pretty closely and I learned a long time
    || ago that plugins don't have much effect (so I don't pay attention to
    || them any more). Here's a (reproducible) comparison between loading eight
    || plugins (all mine) and loading none.
    || ---End Quote---
    |
    | I think it will very difficult to detect Vince.
    | People forget that speed of execution is primarily
    |
    | (i) any file IO that needs to occur
    | (ii) memory allocation/deallocation
    | (iii) superior algorithms (execution of code counts here)
    |
    | Those DLL calls will be dwarfed by the cost of finding and loading
    | the plugin (the file IO). After that, if it is in some cache (that
    | is if Windows has to reload), you are not going to notice. Steve's
    | original request boils down to whether the plugin DLLs are shared or
    | side-by-side DLLs.

    Thanks your replies. I judge from them that if another instance of TCC has
    already loaded the plugins, the pipe or new instance start-up will not be
    significantly impacted by having my plugins in subdirectory PLUGINS and not
    specifying /IP (ignore plugins) in starting a new TCC instance. BTW, a 10%
    increase in my environment is not significant anyway.

    Rex, the quickhelp for TCC v11 lists the /I... option in the command line
    section, but does not list it below, in the option switch explanation
    section.
    --
    Steve
     

Share This Page