XYplorer Beta Club

nas8e9 wrote:

Jibz wrote:I may be dense here, but why on earth can't XYplorer use threads?

It's a limitation imposed by the programming language used to develop XYplorer. I don't think the developer would start developing something in Visual Basic 6 any more, but moving to a modern language with *working* multi-threading support (VB6 lacks the "working" part) would mean starting from scratch. I don't think that likely right now, even though VB6 is also holding back development of a 64-bit version.

That is terrible! Would it be possible to use a more recent version of VB to fix this? or is there something that chains XYplorer to VB6?

I guess this is also the explanation why XYplorer is so sluggish when browsing a folder of images with thumbnails, whereas TC and DO are both as fast as explorer.

Jibz wrote:

nas8e9 wrote:

Jibz wrote:I may be dense here, but why on earth can't XYplorer use threads?

It's a limitation imposed by the programming language used to develop XYplorer. I don't think the developer would start developing something in Visual Basic 6 any more, but moving to a modern language with *working* multi-threading support (VB6 lacks the "working" part) would mean starting from scratch. I don't think that likely right now, even though VB6 is also holding back development of a 64-bit version.

That is terrible! Would it be possible to use a more recent version of VB to fix this? or is there something that chains XYplorer to VB6?

After VB6, Microsoft went with its .NET system which isn't known for its performance and which works quite differently. Previous comments from the developer about .NET weren't favorable.

Jibz wrote:I guess this is also the explanation why XYplorer is so sluggish when browsing a folder of images with thumbnails, whereas TC and DO are both as fast as explorer.

It's purely a question of dividing (blocking) tasks among threads or processes: TC and DO do multi-threading whereas XY can use multiple processes like it already does for file operations. Again, I suspect that in time, more operations will be fielded off to helper processes.

Jibz wrote:That is terrible! Would it be possible to use a more recent version of VB to fix this? or is there something that chains XYplorer to VB6?

VB6's direct successor is Visual Basic.NET, which relies on the .NET framework being present on a client. This framework does not come pre-installed on Win 2000 and XP (Home and Pro). Also, framework's version 3.* and later do not support pre-XP environments, which may be of concern to Don.

On a "good news" front, there is a VB6-to-VB.NET converter that can potentially port over a lot of code -- if Don does decide to go down the .NET yellow brick road -- manual modifications notwithstanding.

Jibz wrote:I guess this is also the explanation why XYplorer is so sluggish when browsing a folder of images with thumbnails, whereas TC and DO are both as fast as explorer.

Have you had a look at options in Configuration | Thumbnails? There are options to create super-fast thumbnails, cache them to disk, etc

nas8e9 wrote:It's purely a question of dividing (blocking) tasks among threads or processes: TC and DO do multi-threading whereas XY can use multiple processes like it already does for file operations. Again, I suspect that in time, more operations will be fielded off to helper processes.

Once the 64-bit version is on the horizon, we can start talking multi-threading as both C++ and .NET support that. Delphi doesn't have a 64-bit compiler to my knowledge at this time. What other languages have 64-bit compilers?

Jibz wrote:I guess this is also the explanation why XYplorer is so sluggish when browsing a folder of images with thumbnails, whereas TC and DO are both as fast as explorer.

And I'm sure you know this but for any others who may not: Remember that XYplorer.exe is the result of compiled VB6 code, and is not interpreted VB code so you can't blame all the slowness on the VB aspect (as paraphrased from some of Don's prior replies).

If XY appears sluggish on icons and thumbs then some unknown other factors must be involved. It has certainly nothing to do with the language the source code is written in (which is compiled to machine code anyway as jc_hallgren already said). I have lots of user statements that confirm that XY is clearly faster than competeting products, and also on both of my own systems (XP and Win7) icons and thumbnails are very fast.

OTOH it is true that those things could be moved to a parallel process. Only that I'm currently working on other things. And "I" am only a single sequential process.

admin wrote:If XY appears sluggish on icons and thumbs then some unknown other factors must be involved. It has certainly nothing to do with the language the source code is written in (which is compiled to machine code anyway as jc_hallgren already said). I have lots of user statements that confirm that XY is clearly faster than competeting products, and also on both of my own systems (XP and Win7) icons and thumbnails are very fast.

I know this is your usual response, and I would accept it if it weren't for the simple fact that Directory Opus and Total Commander both do not appear to suffer from these unknown other factors .

It does not matter how much you optimize the code that retrieves the icon or the thumbnail -- as long as the entire XYplorer application locks up waiting for each operation to finish, it will appear sluggish at best and stuttering at worst.

So yes, it has nothing to do with the language the source code is written in, but rather the way it is written (i.e. what we need here is an algorithmic optimization rather than a code optimization).

There is nothing you can do about outside factors like AV software and similar, which intercept file access to perform some action. The way to solve such problems is to move the work to a separate thread so the main UI remains responsive. Of course this is a problem if VB6 does not support multi-threading .. I am amazed a language from 1998 does not .

Jibz wrote:

admin wrote:If XY appears sluggish on icons and thumbs then some unknown other factors must be involved. It has certainly nothing to do with the language the source code is written in (which is compiled to machine code anyway as jc_hallgren already said). I have lots of user statements that confirm that XY is clearly faster than competeting products, and also on both of my own systems (XP and Win7) icons and thumbnails are very fast.

I know this is your usual response, and I would accept it if it weren't for the simple fact that Directory Opus and Total Commander both do not appear to suffer from these unknown other factors .

It does not matter how much you optimize the code that retrieves the icon or the thumbnail -- as long as the entire XYplorer application locks up waiting for each operation to finish, it will appear sluggish at best and stuttering at worst.

So yes, it has nothing to do with the language the source code is written in, but rather the way it is written (i.e. what we need here is an algorithmic optimization rather than a code optimization).

There is nothing you can do about outside factors like AV software and similar, which intercept file access to perform some action. The way to solve such problems is to move the work to a separate thread so the main UI remains responsive. Of course this is a problem if VB6 does not support multi-threading .. I am amazed a language from 1998 does not .

Agreed. But still it does not explain why the sluggishness you experience only affects a minority of users (for all I know).

admin wrote:Agreed. But still it does not explain why the sluggishness you experience only affects a minority of users (for all I know).

I think it is a combination of a number of factors.

My computer is comparatively slow, the CPU is a single-core AMD, and my HDD is relatively slow. On our other computer (a quad-core beast), the delay is hardly noticeable.

I am running Windows XP, later versions of Windows may have introduced more caching.

The number and type of software that intercept file access and the operations they perform -- I am using MSE, I had the same problem with Kaspersky, but perhaps not quite as pronounced.

The type of files in question -- in my case it's mostly installers in the range from 1-10 mb and image files 2-5 mb.

The folder that I am having the most trouble with contains about 350 executables, 300 other files, and about 100 folders, and it is not one of the Windows system folders.

When I enter the folder the panel is filled with the sub folders, and I can scroll down fine. But as soon as I get down to where some of the executables come into view, XY literally locks up for 1-2 seconds then jumps further down the list, locks again, jumps, etc. In explorer, DO and TC I can scroll freely up and down the list of files without any lockups, and the icons in view start appearing after a short time of standing still.

I think we can easily agree that there is a problem with having the UI wait for file access like this -- the question is if it is safe to ignore the problem because most computers are fast enough that it does not show. Will it rear its head again in other places? What if a user wants to browse a folder of really big images where thumbnails take time to generate even on a fast computer? What if he is browsing executables on a slow removable media?

Actually, looking over this post again made me think of something. The folder I was having the most trouble with contains a lot of installers, most of which are digitally signed. Perhaps it is Windows checking the signature on file access that enhances the problem in this case?

The report from Zigo about the issue in this thread describes a folder of installers as well.

I tried opening a folder of downloaded installers on the other machine (fast quad-core), and to my surprise XYplorer was locking up and jumping like on my old computer!

Jibz wrote:Actually, looking over this post again made me think of something. The folder I was having the most trouble with contains a lot of installers, most of which are digitally signed. Perhaps it is Windows checking the signature on file access that enhances the problem in this case?

The report from Zigo about the issue in this thread describes a folder of installers as well.

I tried opening a folder of downloaded installers on the other machine (fast quad-core), and to my surprise XYplorer was locking up and jumping like on my old computer!

It's an idea, but I have no information about these things.

Technically retrieving the icons from ICO files also needs the files to be opened, just like EXEs. So if you have a folder full of ICOs it should show the same speed and a folder full of EXEs. If not it would point to your idea that EXEs get special treatment by Windows.

BTW, note that only the icons of the files currently visible in the list are retrieved. So it is not relevant how many files are in the folder, but how many files are visible in the list at any point in time. This means if you are using the "List" view mode you will perceive considerably more sluggishness than with details mode.

admin wrote:Technically retrieving the icons from ICO files also needs the files to be opened, just like EXEs. So if you have a folder full of ICOs it should show the same speed and a folder full of EXEs. If not it would point to your idea that EXEs get special treatment by Windows.

I have conducted a little informal testing on this, if you will bear with me.

I created 3 folders (icons, signed, and unsigned) and from the command prompt I created 20 copies of the same icon file in icons, 20 copies of a digitally signed exe file in signed, and 20 copies of an unsigned exe file in unsigned. The signed executable I used was the installer for doPDF, the unsigned executable was the installer for FileZilla Client -- they are both around 4 MB in size.

I then entered each folder in turn, and timed (using a regular stopwatch) roughly how long it took before all the icons were shown in the list. I did this test with XYplorer, then rebooted (to clear any cache) and did it with Total Commander on a fresh copy of the folders.

I performed this test on two machines; my comparatively slow Athlon64, and a fast quad-core Intel machine.

Icons

XY Slow machine: ~1 second
TC Slow machine: ~1 second

XY Fast machine: instant
TC Fast machine: instant

Unsigned executables

XY Slow machine: 14 seconds
TC Slow machine: 15 seconds

XY Fast machine: 6 seconds
TC Fast machine: 6 seconds

Signed executables

XY Slow machine: 56 seconds
TC Slow machine: 56 seconds

XY Fast machine: 30 seconds
TC Fast machine: 29 seconds

What I gather from this is:

• Something in Windows (or possible MSE, but my bet is Windows) cheks the signature on digitally signed executables when the icon is being retrieved.
• The time spent doing this does not depend on the file manager used -- XY and TC are equal
• Even on a fast machine, retrieving an icon from a signed executable takes a noticeable amount of time (~1.5 seconds), on a slow machine it feels like forever (~2.8 seconds)

The real difference between XY and TC, however, is responsiveness. During the 30 seconds it took to load the icons on the fast machine, I could move around the file list and browse through other folders in the other pane in TC just fine, whereas XY locks up for 1.5 seconds, then the cursor jumps, lockup again, etc.

Once the icons are cached, both are of course equally fast and there are no problems, until the cache is cleared again.

(In case anyone wants to do their own testing, make sure you set up the test files from the command prompt or similar, so you do not get all the icons cached.)

1.5 seconds per file is scandalous. What the hell is going there?

Anyway, the solution is clear (putting it to separate thread). The day will come...