History loading slow

[nikbackm]

I have noticed that loading the history at first TCC instance startup using HISTORY /R seems to be quite slow.

My current history.sav file is ca 500KB large and contains about 10,000 entries. When TCC starts up and loads this file it keeps the CPU at 90-100% load for some ten seconds. This seems to be a bit slow for modern machines (1.5 - 3GHz Pentiums with 2GB RAM). The process pegging the CPU is TCC.EXE.

It's not a particular problem for me since I use SHRALIAS which means it usually happens only after a reboot. Still something that could easily(?) be improved.

My history is configured so it uses unique entries which should force each line in the history file to be checked for uniqueness as it's read, but if a hashtable is used this should not be a slow operation.

 

[Steve Fabian]

JP Software Forums" <[email protected]>; "nikbackm wrote:
| I have noticed that loading the history at first TCC instance startup
| using HISTORY /R seems to be quite slow.
|
| My current history.sav file is ca 500KB large and contains about
| 10,000 entries. When TCC starts up and loads this file it keeps the
| CPU at 90-100% load for some ten seconds. This seems to be a bit slow
| for modern machines (1.5 - 3GHz Pentiums with 2GB RAM). The process
| pegging the CPU is TCC.EXE.
|
| It's not a particular problem for me since I use SHRALIAS which means
| it usually happens only after a reboot. Still something that could
| easily(?) be improved.
|
| My history is configured so it uses unique entries which should force
| each line in the history file to be checked for uniqueness as it's
| read, but if a hashtable is used this should not be a slow operation.

In my Windows "Startup" directory I have a shortcut to an instance of TCC,
which just loads SHRALIAS, and populates the alias, function, history, and
directory history tables, then quits. In WinXP this shortcut is activated
each time I log in. While my logging in itself is slow, this is done before
even the first normal use of TCC, so I am not actually bothered by however
long the process takes, esp. since I have a number of other slow operations
also triggered there, e.g., Outlook Express downloading all new email
(including the JPsoft newsgroups) and newsgroup messages.
--
HTH, Steve

 

[BillMc]

On Mon 6-Oct-08 6:31am -0600, nikbackm wrote:

.> My current history.sav file is ca 500KB large

The help files for 4nt and tcc show a maximum size of the
command history of 128k. How did you set it up to get 500k?

--
Best regards,
Bill
4nt 8.02.106 / tcmd 9.02.152 cp 2.11.34 on xp pro sp3

 

[rconn]

nikbackm wrote:

> I have noticed that loading the history at first TCC instance startup
> using HISTORY /R seems to be quite slow.
>
> My current history.sav file is ca 500KB large and contains about 10,000
> entries. When TCC starts up and loads this file it keeps the CPU at
> 90-100% load for some ten seconds. This seems to be a bit slow for
> modern machines (1.5 - 3GHz Pentiums with 2GB RAM). The process pegging
> the CPU is TCC.EXE.
>
> It's not a particular problem for me since I use SHRALIAS which means it
> usually happens only after a reboot. Still something that could
> easily(?) be improved.
>
> My history is configured so it uses unique entries which should force
> each line in the history file to be checked for uniqueness as it's read,
> but if a hashtable is used this should not be a slow operation.

The problem is your history file is (much) larger than the maximum
history size, so TCC is spending most of its time deleting the earlier
entries and moving the list to make room for the later entries.

Rex Conn
JP Software

 

[vefatica]

On Tue, 07 Oct 2008 21:46:24 -0500, "JP Software Forums" <[email protected]>,rconn
<> wrote:

>The problem is your history file is (much) larger than the maximum
>history size, so TCC is spending most of its time deleting the earlier
>entries and moving the list to make room for the later entries.

Using the log file saves having to "history > history.sav" upon exit. Perhaps
when "history /r file" is given, the file pointer could automatically be
positioned at the maximum of

the beginning of the file

file_size minus history_size_in_bytes

and, if not at the beginning of the file, moved to the beginning of the next
line before populating the history list.

It seems that would be easy and harmless.

 

[nikbackm]

nikbackm wrote:



The problem is your history file is (much) larger than the maximum
history size, so TCC is spending most of its time deleting the earlier
entries and moving the list to make room for the later entries.

Rex Conn
JP Software

I don't think that can (or should) be the cause since the history file that is loaded by the first TCC instance is the same one written by SHRALIAS when it exits.


JPSoft>wc history.sav
10275 27378 489166 history.sav

JPSoft>history | wc
10275 27374 234307


The file and the history contains the same number of entires (10275), if HISTORY /R is forced to discard entries as it reads the file should not the history contains less entries than the file?

Note: For some reason SHRALIAS seems to write Unicode files, hence double the size in bytes for the file as my wc.exe is not Unicode aware. The file probably also has line end characters.

My History Buffer Size is set to 249856. I changed it to that after the notification that its max allowed size had been doubled (but the help files still has the old value of 130K).

And I am running TCC 9,02.149 Windows XP [Version 5,1,2600].