Performance issues in 8.6.1

HW · Post by HW » Tue Apr 20, 2021 11:09 am

Our users experience performance issues in the latest version 8.6.1.
They mostly do find&replace (e.g. replace & with &) in large xml-files, up to 2.5 GB.

After updating to 8.6.1 TextPad is "not responding" for an umlimited time while CPU load in Precess manager is still showing action when processing such files.
Smaller files (approx. 600 MB) are being processed well.

Processing the same large file with an old version 8.2 is working fine.
The users did not complain about that issue before.

Is this an known issue and is there an update in planning?

Post by **bbadmin** » Fri Apr 23, 2021 11:20 am

Thanks for reporting this behaviour and we respond again as soon as we have concluded our tests.

Post by **bbadmin** » Wed May 12, 2021 5:24 am

Apologies for the delay in resolving this issue, but we were holding off until version 8.7 was complete. This is now available and features an editor for keystroke macros.

Keith MacDonald
Helios Software Solutions

HW · Post by HW » Tue Oct 11, 2022 6:40 am

Coming back to this thread because the issue still occur.

I did some testing with the last releases up to 8.13.
Mass replace in test file (xml, 916 MB, 22.5m lines, 95.5m chars, 337k occurrences, local storage).
In my testing the changes are just 2 chars added, removed or changed.

Version 8.13 an prior:
If the replacemant text is shorten or same lenght as the original, then the mass replace took around 1.20 min.
If the replacement text is extended, TextPad is not responding indefinitely.

This does not happen in Version 8.2, which the affected users as a workaround are working with. How ever, this cannot be a final solution because the Version gap becomes bigger and bigger.

We purcheaed TextPad because some it can manipulate even very large files which is neccessary for some of our users.

Post by **AmigoJack** » Tue Oct 11, 2022 8:23 am

I created a text file out of executing DIR /s C:\ > BIG.TXT again and again, which then had:

1052348516 characters
92352058 words
18715466 lines
1089779352 bytes (0.99 GiB)

Using TextPad 8.4.2x64 replacing <DIR> with <dir> (same length) took the same time (about 100 seconds for 3313776 occurences) as replacing it with <directory> (longer). Both times I opened the text file afresh, preventing to do both operations on the same file (session) which would most likely increase the undo cache. Doing both replacements in a row on the same file (session) however did not change anything: it was also that fast in both actions. My replacing options were:

match case insensitive
no regular expressions

The system having tested this has

16 GiB of RAM
8.4 GiB of RAM occupied with TextPad having said file open
4.5 GiB of RAM occupied without having said file open
Windows 7x64
running only 67 other processes, using the CPU at about 20%
CPU is Intel Core 3.2 GHz with 4 cores

Maybe the text encoding makes a difference? Up until now it was interpreted as "Windows-1252", so I saved it as "UTF-8" with BOM, then reopened the file afresh. Repeating both replacement actions in a row did not took significantly different times, tho.

One difference to XML: no syntax highlighting - maybe that's a culprit?

HW · Post by HW » Tue Oct 11, 2022 11:21 am

The production machine is Windows 10x64, running on Hyper-V (16 GB RAM fix, 4 CPU).
The file opened in TextPad allocates around 2.5 GB RAM.

The same xml-file open in TextPad 8.2 (which ist quite close to your version 8.4.2) works pretty much like yours.
My replacing options are default.

The Users complain after updating to Version 8.6.1 x64.

In 8.6.0 there was a change "Speeded up the Replace All command to split very long lines of text.".
Our files contain some lines up to 2600 columns.

Post by **AmigoJack** » Tue Oct 11, 2022 1:51 pm

Manipulating my file to have 2 lines with ~4000 characters (and also matches in there to be replaced) took only a little bit longer, but still finished as expected. So maybe it's not about a big filesize, maybe it's only about long lines...?

HW · Post by HW » Wed Oct 12, 2022 6:38 am

Same here, as long as working with TextPad 8.2.

The behavior is different when using TextPad 8.6.1 an newer.
Issue might be in earlier versions already and the users just kept quiet.
The reporting user mentioned he used his private TextPad 8.2 to work around.

I manipulate only shorter lines up to 80 chars.

Post by **bbadmin** » Sat Nov 05, 2022 6:09 pm

This behaviour will be fixed in the next release which is coming soon.