Problems with Imatch 2017 on Windows 10 guest in Virtualbox 5.2.12

[CollieDog]

Hi,
I'm wondering if anyone has a solution for me.

For a variety of reasons, I switched to Linux Kubuntu several years ago.
Because IMatch is the only Windows program I still need, I installed IMatch 2017 on a Windows 10 guest in Virtualbox 5.2.12.
Most software runs fairly well in Virtualbox, but IMatch does not.

My system is quite capable:
- Intel core i7 6700
- 32 gb RAM
- dual 500gb Samsung SSD
- 2gb video card[/li][/list]

I have deliberately NOT installed a virus or malware scanner on the virtual Windows 10 operating system to avoid problems.

I have Virtualbox set up as follows:
- 10 gb RAM
- 4 processors
- Hardware visualization turned on (including Enable VT-x/AMD-V and Enable Nested Paging)[/li][/list]


I would guess that these settings should be more than sufficient to run IMatch 2017 smoothly.
Quite unexpectedly, it runs poorly with many long lags that result in a popup message asking if I want to terminate. If I simply wait long enough (between 2 to 5 min) IMatch usually responds after performing relatively simple procedures like adding keywords and descriptions to 200 photos.

Dragging and dropping more than 3 folders (each holding about 8-10gb of images) from Windows 10 Explorer into IMatch 2017 also often results in long delays or crashes. I found it runs far better if I select only 2 at a time and drag and drop.

Any suggestions on how I can obtain better performances?  IMatch is one of my favorite applications EVER.


A supplemental note:
I do not want to dual boot Windows 10 and Kubuntu via GRUB because somehow, Windows 10 updates consistently corrupt the bootup procedures and prevents Linux from booting. A Linux guru buddy is not able to fix these corruptions and thus Windows 10 has been banished from my system.  I will try using BIOS boot-disk order to install Windows 10 on a separate disk. Theoretically, at boot-up, I can choose in bios the boot order of disks and thus select either Window 10 or Linux. Windows 10 should be totally isolated from Linux and thereby unable to break it. Has anyone done this?

[Mario]

I use VirtualBox instances to test IMatch. No problems.

You did not provide sufficient info, e.g. a zipped IMatch log file.
Or details like

Where are the images stored?
Where is the database stored?

To me this sounds as if everything related to file I/O very slow and since IMatch is all about file I/O, this will slow IMatch down to a crawl.
The database should be located on a SSD, not filtered through a simulated network stack into VirtualBox, for example.

[CollieDog]

Hi,

Sorry for omitting key details.

Very good news to hear that Imatch runs well in a virtual machine for you.

I've attached the log file.
The database, now 7gb in size, is stored on a standard 4tb Seagate NAS grade harddrive installed in the computer's tower case.
The Linux OS is installed on a Samsung SSD along with all software.

I guess I should move the database to an SSD.

Is there anything strange going on in the log file?

Thank you

[Mario]

The database, now 7gb in size, is stored on a standard 4tb Seagate NAS grade harddrive installed in the computer's tower case.

Worst-case, performance wise. Especially if you also access this over a simulated bridged network from inside VirtualBox.

[CollieDog]

What does "worst case" mean? The way I had it set up?
Was there anything in the log indicating other complications?

I have moved the database to a separate SSD. Linux and programs are located on one SSD, with the VM and Imatch catalogue located on another SSD.
I'll check the performance.

Thank you!

[Mario]

Code Select Expand

The database, now 7gb in size, is stored on a standard 4tb Seagate NAS grade harddrive installed in the computer's tower case.

I commented on this. Because:

1. NAS storage: Already much slower than SSD
2. Every read/write operation (and IMatch may do thousands per minute) has to go over the network.
3. Since you run IMatch also in a VM, the traffic between the VM and the host operating system also has to go through a simulated bridged network adapter.

=> Many extra levels, many transfers and mappings, very slow database operations.

Best case: IMatch runs on Windows and uses a database on the same computer, stored on a SSD. This is the default for most users, thankfully.
Like all database systems, IMatch's performance stands and falls with the performance of the disk.

[Jingo]

It would be interesting to get speed metrics for this type of VM setup.  When I was running IM in a virtual machine on my MAC - I ran into some pretty large performance issues.  The software was still very usable - but nothing compared to how it runs natively in Windows on a SSD as Mario suggests.

[Mario]

I use VMs and container for testing purposes.
You get a quite usable performance when you copy the database to the disk "inside" the VM. I run all VMs and containers with disks on SSD storage.

If you add several layers on top to reach a remote NAS, performance will inevitably degrade.