Finally, did it...

[Mario]

Since I've integrated the Chromium Browser in IMatch 2017 I always wanted to change the way it interfaces with IMatch.

Currently, IMatch starts multiple copies of itself, for hosting the Chromium browser process (you can see that in the Windows Task Manager). The more app panels are open or apps are running, the more copies of IMatch are in memory. Of course these IMatch instances don't need as much memory as the instance managing the database, but they require about 150 MB RAM each, which adds up quickly...


Here is my Task Manager when I use the App Manager, 2 App Panels and a modal app at the same time:



The highlighted instance is IMatch managing a very small database (280 MB) and the other instances require 140 and 180 MB each just to host the Chromium browser.
Thinking about running even more apps (e.g. app-based File Windows in the future or entire Views) and service apps, this would escalate quickly.

But far more important is that (for complex technical reasons) Chromium is unable to employ certain optimizations and isolation techniques in this mode, which is bad, especially for graphics performance. You won't notice this in normal apps, but I have some apps in planning which will benefit a lot from Chromium being able to use the graphic card natively. And some other features.

I have tried several times in the past to switch to using a mode which uses a dedicated executable just for hosting Chromium and then using special communication techniques to make all the app magic work as before. Never got it to work. Strange errors, crashes, stalling browsers and more. I always gave up after a day of fiddling...many other things to do.

Yesterday, while upgrading Chromium to the latest version (I do that every one or two months) I had yet another idea of how to get this to work. And HEUREKA, I did it

The reason for the problem was complex, but once I figured it out, it was easy to handle. Basically just changing some configuration options for the IMatchChromiumHelper executable I have written. Frankly, dealing with Chromium and related components is really complicated, but worth the effort.

Besides Chromium now being happier then ever before inside IMatch, the memory footprint has reduced dramatically as well:



A small app now only requires 20 to 50 MB RAM, instead of 150MB!

[ben]

Thanks for keeping us updated.
Sounds like good work on the backend.
Now, when can we expect imatch2018? 😉

[Mario]

Now, when can we expect imatch2018? 😉

As soon as I'm satisfied with it.

[mastodon]

That sounds great!  I am also waiting for the new IMA.

[Mario]

That sounds great!  I am also waiting for the new IMA.

As far as I can tell now, I will first release IMatch 2018, and a compatibility update for IMatch Anywhere 2017 (so it can handle the IMatch 2018 databases).

I guess it will take about six more weeks after the release of IMatch 2018 to release IMatch Anywhere 2018.
After IMatch 2018 is out, stress and work levels will reduce and I can concentrate on IMA 2018 alone. The server part is almost done, but there are some things to do with the WebViewer.

[StanRohrer]

I also see a half dozen or more occurrences of exiftool.exe in the Task Manager processes. Will your fix also reduce those seemingly spurious entries?

[Mario]

IMatch runs multiple ExifTool instances in parallel, this is intentional. IMatch does this to increase performance by processing multiple files in simultaneously.
The number of ExifTool instances depends on the number of CPU cores in your system and what you do (ingesting files, writing back, ...)
The memory consumption of ExifTool is usually negligible, like, 20MB each.

[Menace]

I also see a half dozen or more occurrences of exiftool.exe in the Task Manager processes. Will your fix also reduce those seemingly spurious entries?

IMatch is finally a software who use more then just 4 Cores/8 Threads. IMatch is very modern compared to a lot of other software (even Adobe Products are limited in using Multithread). Modern CPU (since AMD start to sell there Ryzen) are powerful Multicore-CPUs which can have 8 Core/16 Threads or even more (i.e. AMD Threadripper).