Slickedit very slow on 10M file

[astromme]

Code: [Select]

SlickEdit Pro 2023 (v28.0.0.6 64-bit Qt5)

Licensed number of users: Single user
License file: /opt/slickedit-pro2023/bin/slickedit.lic

Build Date: November 2, 2023
Emulation: Brief

OS: Linux
OS Version: Ubuntu 22.04.3 LTS
Kernel Level: 6.2.0-060200-generic
Build Version: #202302191831 SMP PREEMPT_DYNAMIC Sun Feb 19 23:37:22 UTC 2023
Processor Architecture: x86_64

X Server Vendor: The X.Org Foundation


Window Manager: GNOME Shell
Display manager: /usr/sbin/gdm3

Memory: 98% Load, 25360MB/25872MB Virtual
Shell Information: "/opt/slickedit-pro2023/bin/secsh" -i
Screen Size: 1920 x 1080 (11520 1080), 3840 x 2160 (7680 0), 3840 x 2160 (3840 0), 3840 x 2160 (0 0)

Project Type: Single file project - Other
Language: No file open
Encoding: No file open

Installation Directory: /opt/slickedit-pro2023/
Configuration Directory: /home/stromme/.slickedit/28.0.0/
Migrated from: /home/stromme/.slickedit/26.0.3/


While trying to search through a file on the order of 10-20 MB, Slickedit is VERY slow.. taking ones of seconds to respond to cursor movement, or search-again.

[astromme]

The file includes lines that are over one million characters long.

[Dan]

What kind of files are they? Are they in version control?

[astromme]

No.  They're log files that happen to have json in them.  The json blobs are the very long parts.

[Clark]

Can you provide a sample file we can use to reproduce this?

[Clark]

I added a hot fix for a performance problem having to do with mousing over a long line. This performance problem won't happen with any long line but with the right long line it will happen every time.

Please try the latest hot fix for v28 and post your results here:

https://www.slickedit.com/hotfixes

Thanks

[astromme]

I applied the hotfix.  I don't still have the file that was causing problems, so I did this:

Code: [Select]

yes > test.txt
truncate test.txt --size=1000000Make sure you hit control-C on the yes command immediately cause that file gets big PDQ.

Then I opened the file in SlickEdit and did a replace of \n to nothing.  SlickEdit hangs for a while, then shows that it did SOME of the find/replace in the window while the search/replace is still active, then if I switch away to another window, offers to stop searching.  I look at the file and there's about 250k ys on a single line, and about 250k on separate lines.

I can't necessarily say this is the same thing as my original problem.

[Clark]

You would need the your original json file to be sure this fixed your original performance problem (Especially since json is color coded and txt files are not).

The problem I ran into is a test file I had which was 1 gig of 'a' characters (nothing else!). On Linux, SlickEdit would take a while to split the lines into 4-8k chunks when opening the file (no bug there). However, then when you hovered your mouse over the crazy amount of 'a' characters a hex regex would take forever because it was matching all of them. The fix was trivial. Simple to change the regex to only match up to 32 hex characters. I also fixed some other regex number matching which matched other character sets.

[astromme]

Found the file - PMing a link.

[Clark]

Are there some steps I should do to see an issue?

[astromme]

Not really.. opening the file is slow, clicking away and clicking back to SlickEdit is slow, arrowing around is slow until the delay goes away, searching and list matches is slow.  Most delays are on the order of 5 seconds or so before SlickEdit becomes responsive again.

[Clark]

I'm not surprised you might get slow searching. However, it sounds like you are getting slow scrolling. I get slow scrolling in a debug build but not in a release build. I'm testing on a laptop:

quad core model: Intel Core i7-1065G7

What are the specs of your machine?

Try a clean config and opening your log file (vs -sc /tmp/tempconfig) and scrolling around.

[astromme]

14 core i7-12700H with 32GB RAM.

A new profile seems to not have any slowdown.

[Clark]

Possibilities:

* Could be due to something in user.cfg.xml which has most configuration data
* Could be due to a project you have open. New config doesn't have a complex project open.
* Could be due to a particular tool window being open and active. New config resets the tool window configuration.

This could definitely be a fixable performance problem. We just need to narrow it down.