I have just compared the running of my "make" procedure under 4NT V4.00a and TCC 9.02.151 and TCC is so much slower. In some operations eg. make clean which deletes files it is 4x slower. Can anyone explain this? I have removed the Folder and List view in case this was being continuously updated.
Slow execution
- Thread starter gmorris59
- Start date
There are a couple of things that might be causing your slowdown.
1.) You might be deleting to the Recycle Bin.
2.) If you are deleting directories, then your extended directory search
database (jpstree.idx) will be updated also.
Use the /K switch on DEL to force physical delete instead of moving to the
recycle bin.
Use the /Nt switch to prevent updates to the JPSTREE.IDX file.
-Scott
"JP Software Forums" <neil@jpsoft.com> wrote on 11/11/2008 05:40:35 AM:
1.) You might be deleting to the Recycle Bin.
2.) If you are deleting directories, then your extended directory search
database (jpstree.idx) will be updated also.
Use the /K switch on DEL to force physical delete instead of moving to the
recycle bin.
Use the /Nt switch to prevent updates to the JPSTREE.IDX file.
-Scott
"JP Software Forums" <neil@jpsoft.com> wrote on 11/11/2008 05:40:35 AM:
I have Delete to Recycle bin off
I will try and use the /Nt switch
Is there a way to switch off the JPSTREE.IDX during the make ?
I will try and use the /Nt switch
Is there a way to switch off the JPSTREE.IDX during the make ?
JP Software Forums" <neil@jpsoft.com>; "gmorris59 wrote:
| I have Delete to Recycle bin off
| I will try and use the /Nt switch
| Is there a way to switch off the JPSTREE.IDX during the make ?
Use the environment variable TreeExclude to specify the root of the
directory tree you delete, or even the root directory of the drive where
it's located, e.g.:
set TREEEXECLUDE=d:\myproject\objectfiles
or
set TreeExclude=d:\
Another method is to use the TreePath initialization directive, which
specifies the directory where JPSTREE.IDX is located. Specify any directory
where there is not file named JPSTREE.IDX:
option //TreePath=c:\temp
and the time to update the index file will be minimized.
--
HTH, Steve
| I have Delete to Recycle bin off
| I will try and use the /Nt switch
| Is there a way to switch off the JPSTREE.IDX during the make ?
Use the environment variable TreeExclude to specify the root of the
directory tree you delete, or even the root directory of the drive where
it's located, e.g.:
set TREEEXECLUDE=d:\myproject\objectfiles
or
set TreeExclude=d:\
Another method is to use the TreePath initialization directive, which
specifies the directory where JPSTREE.IDX is located. Specify any directory
where there is not file named JPSTREE.IDX:
option //TreePath=c:\temp
and the time to update the index file will be minimized.
--
HTH, Steve
dbartt wrote:
| ---Quote---
|| Is there a way to switch off the JPSTREE.IDX during the make ?
| ---End Quote---
|
| OOPS. Left out a line
|
| You can do this:
|
| set SaveValue=%@execstr[option fuzzycd] & rem save current
| JPSTREE.IDX setting option //fuzzycd=0
| make
| option //%SaveValue & rem Restore JPSTREE.IDX setting
Sorry, that does not work, or at least it did not work in earlier versions.
I did not test it in TCC. The reason is that JPSTREE.IDX updating is
independent of the CURRENT setting of configuration directive FuzzyCD.
--
Steve
| ---Quote---
|| Is there a way to switch off the JPSTREE.IDX during the make ?
| ---End Quote---
|
| OOPS. Left out a line
|
| You can do this:
|
| set SaveValue=%@execstr[option fuzzycd] & rem save current
| JPSTREE.IDX setting option //fuzzycd=0
| make
| option //%SaveValue & rem Restore JPSTREE.IDX setting
Sorry, that does not work, or at least it did not work in earlier versions.
I did not test it in TCC. The reason is that JPSTREE.IDX updating is
independent of the CURRENT setting of configuration directive FuzzyCD.
--
Steve
Yes, you're right. FUZZYCD seems to control how the index is searched but not
the update process. Updating of the index file seems to be governed by the
existence of JPSTREE.IDX. If it exists, it will be updated unless TREEXCLUDE is
specified or TREEPATH is used as you suggested.
I have in fact disabled the Extended Directory Search (set at level 0) and also removed the index file but it is still twice as slow as 4NT? Could it just be a slower product ie. more functionality but slower? I also see that in the Task Manager that tcc even if doing nothing occassionally uses 1% of CPU. Could this be the update of the status bar?
gmorris59 wrote:
| I have in fact disabled the Extended Directory Search (set at level
| 0) and also removed the index file but it is still twice as slow as
| 4NT? Could it just be a slower product ie. more functionality but
| slower? I also see that in the Task Manager that tcc even if doing
| nothing occassionally uses 1% of CPU. Could this be the update of the
| status bar?
Please make the distinction here between TCMD.EXE (the GUI tab manager,
which also contains the status bar, and the other GUI panels), and TCC.EXE
(the command processor, which in your experminet apparently runs in one of
the TCMD tabs). For a true performance comparison, you should compare the
performances of 4NT.and TCC.EXE when they are both in TCMD tabs, or when
they are in their own windows (stand-alone, neither one in a TCMD tab).
Please consider also the issue of possible OS caching. Starting and running
a program is very much slower if other applications have forced it out from
the various caches maintained by Windows, particularly the disk cache. I
noticed that starting programs the first time in the morning, after the
overnight run of my virus scanner, is very slow. Starting the same programs
later in the day, after other programs had taken over the caches, is slower
than rapidly repeated starts, but not to the same degree.
--
Steve
| I have in fact disabled the Extended Directory Search (set at level
| 0) and also removed the index file but it is still twice as slow as
| 4NT? Could it just be a slower product ie. more functionality but
| slower? I also see that in the Task Manager that tcc even if doing
| nothing occassionally uses 1% of CPU. Could this be the update of the
| status bar?
Please make the distinction here between TCMD.EXE (the GUI tab manager,
which also contains the status bar, and the other GUI panels), and TCC.EXE
(the command processor, which in your experminet apparently runs in one of
the TCMD tabs). For a true performance comparison, you should compare the
performances of 4NT.and TCC.EXE when they are both in TCMD tabs, or when
they are in their own windows (stand-alone, neither one in a TCMD tab).
Please consider also the issue of possible OS caching. Starting and running
a program is very much slower if other applications have forced it out from
the various caches maintained by Windows, particularly the disk cache. I
noticed that starting programs the first time in the morning, after the
overnight run of my virus scanner, is very slow. Starting the same programs
later in the day, after other programs had taken over the caches, is slower
than rapidly repeated starts, but not to the same degree.
--
Steve
