Slow starting and quitting (1.70.2 and above)

[xnview]

Just stumbled over this problem again, and want to bring it back on the table:
I've put XnView on a USB memory stick and started it directly from the USB stick. Starting XnView takes some seconds which is o.k., but when exiting XnView takes about 2.5 minutes (!). In the Windows task manager the process XnView can be seen and the LED of the USB stick keeps blinking during the whole time, it's XnView saving the .ini file that causes this.

Very strange. How many bytes have your xnview.ini?

Then I've checked the setting "Use regisry to save options" in Options > Install, then the problem dissappeared, XnView exited immediately.
Please note that the memory stick is used at an USB version 1.0 port, which is slow when writing single files. Also, McAfee VirusScan 7.0 is active.
Even if it's a problem of Windows or the antivirus program, I think something should be done about this. As a quick solution, settings could be saved in Windows registry rather than the .ini file.

Many users do not want to use registry.
Perhaps a question after the first startup???

[helmut]

Very strange. How many bytes have your xnview.ini?

It's 7 Kb - not an unusual size I think.

Many users do not want to use registry.
Perhaps a question after the first startup???

I also prefer the .ini files and think this should remain the standard. So we should really solve this problem. Perhaps you can provide me a special debug version that allows you to find out which function / API calls need all the time.

[Dreamer]

I like ini files too, but I think using of registry and adding a feature "Export options to *.reg file" could solve this problem easier, especially if xnview is always(?) slower with an ini file.

[helmut]

I like ini files too, but I think using of registry and adding a feature "Export options to *.reg file" could solve this problem easier, especially if xnview is always(?) slower with an ini file.

Rather than building (more or less) workarounds for exporting the registry settings more easily, I'd like to see the saving of .ini files fixed.
Pierre now could successfully reproduce the "Slow saving" problem and I think in version 1.76 this will be fixed.

[ckit]

I like ini files too, but I think using of registry and adding a feature "Export options to *.reg file" could solve this problem easier, especially if xnview is always(?) slower with an ini file.

Rather than building (more or less) workarounds for exporting the registry settings more easily, I'd like to see the saving of .ini files fixed.
Pierre now could successfully reproduce the "Slow saving" problem and I think in version 1.76 this will be fixed.

Sorry if this moves a little off track but what happened to XnView v1.75?

[helmut]

Sorry if this moves a little off track but what happened to XnView v1.75?

FAIK, XnView 1.75 is an non-official release for a specific customer. So next public/official release is 1.76 (or higher).

[Wen]

I am using 1.80.1. I have tried several versions, they all have this problem.

I tried the things mentioned in the thread: use windows registry and disable virus scan. They did not help on my system.

I find:
1. exiting from viewing a file on my local hd takes less than 1 sec.
2. exiting from viewing a network shared file takes more than 15 secs.

For 2 the time varies. I can see xnview takes about 2-3% of the CPU. The network usage goes way up. It seems it is reading the entire tree from root. By root I mean, windows desktop, expands my computer, (list all my drives), my network places. It expands all the computers on the network. I verified the exit time is about the same time to refresh the browser tree.

I suspect it reads the reads or update the browser tree. When exiting the app, I do not see a need for this. I tried a few options but none helped.

BTW, do you provide source for Xnview?

[Wen]

Another thing I tried is when I first enter browser view first, let it finish update the tree, then exit takes less than 1 sec.