Performance issue with "Truncate filenames in the middle" option in XYplorer

[spinear]

Environment:

XYplorer v28.10.0201 (64-bit)
Windows 11 25H2
Screen scale: 100%

Issue:

• When the option Truncate filenames in the middle is enabled, XYplorer becomes noticeably slower.
  The more characters are truncated from filenames, the worse the performance gets.

How to observe:

• Most noticeable in Thumbnail View.
  Requires a large number of files displayed at once (in my case, about 45 thumbnails per screen).

Steps to reproduce:

• Prepare image files with filenames longer than 100 characters (in my case, Folders where this phenomenon occurs have an average of 130 characters).
  File format does not matter.
  Thumbnail provider does not matter.

• Switch to Thumbnail View.
  Resolution does not matter, but smaller thumbnails (e.g., 64) make truncation more severe and performance slower.
  Set thumbnail captions to multiple lines (I use 3 lines. With 2 lines, it gets even slower).

• Change thumbnail size to increase or decrease the number of truncated characters.
  Or try changing the number of files displayed on one screen.
  Performance changes accordingly.
  Actions like scrolling, drag-selecting, or keyboard input all show the slowdown.

Notes:

• I cannot confirm whether this issue existed in earlier versions.
  I enabled this option long ago because extensions are not shown in Thumbnail View.
  I only noticed the performance degradation in certain folders, and discovered it is directly related to this option today.

[admin]

I don't see this here.

I only noticed the performance degradation in certain folders, and discovered it is directly related to this option today.

If it only happens in certain folders, there must be another factor.

[spinear]

I don't see this here.
If it only happens in certain folders, there must be another factor.

That meant only that the folder contained files with long names. The other folders had short names, so they weren’t affected.

[highend]

Does that mean that in shorter paths (less than 130 chars), you don't have the same problem with files that still have 100 chars on average?

What happens if you copy over such a folder where it happens into "C:\Tst", no speed problems anymore?

[spinear]

Does that mean that in shorter paths (less than 130 chars), you don't have the same problem with files that still have 100 chars on average?

What happens if you copy over such a folder where it happens into "C:\Tst", no speed problems anymore?

This happens because filenames are truncated in the middle. Regardless of the folder path length(I've tested C:\123), if the filename itself is long and a large number of characters are cut off, the slowdown corresponds to the number of truncated characters.

For example, if truncating 50 characters causes a 10% performance drop, then truncating 100 characters results in about a 30% drop. And when dozens of such files are displayed on the screen, the performance degradation stacks up.

[admin]

Can anyone reproduce this?

[highend]

Ok, can confirm this...

Don, copy a .jpg file into C:\tst1, name it 000.jpeg

Run this script:

Code: Select all

    $file = "C:\tst1\000.jpg";
    while ($i++ < 100) {
        $pattern = strrepeat("0", 3);
        $new = format($i, $pattern);
        copyitem $file, "$new.jpg";
    }

now copy the same .jpg file into C:\tst2, name it 000.jpeg again.

Run

Code: Select all

    $file = "C:\tst2\000.jpg";
    while ($i++ < 100) {
        $pattern = strrepeat("0", 130);
        $new = format($i, $pattern);
        copyitem $file, "$new.jpg";
    }

Now try a drag selection in both of these folders (after switching to 64x64 thumbnail view)
In tst1 it's practically instant in tst2 it takes a few seconds before even the dragged zone appears

[admin]

Thanks, gotta go now, will test tomorrow.

[spinear]

Phew… thank goodness.
It was really hard to explain with my limited English.
Even with GPT’s translation help, I still struggled to convey the core idea.

[admin]

Okay, issue confirmed. The next beta will be much faster (though still noticeably slower than end truncation).

[spinear]

Thanks for the fix. 28.10.0202 It's noticeably faster now!