Thank you very much for your business and valuable feedback! Please be rest assured that we are always working hard trying to get as much out as possible!

Hi Chris,

You can download the multi-DLL build directly from our download page. See here for instructions:

http://www.essentialobjects.com/doc/6/install/multi_dll_build.aspx

Thanks!

Hi Crenzi,

Yes. This is normal. The multi-DLL build will reduce memory usage and the total amount of memory still increases when number of tabs increases.

Thanks!

Hi,

There is no separate multi-DLL installation package for 2015 and 2016. Since 2016, the optimization used for the old multi-DLL package has been merged into the main package. So there is no need to have a separate installation for that.

Thanks!

Hi,

This issue is already closed. As mentioned in one of the previous replies, the optimization used in the multi-DLL builds has already been merged into the main build. So there is no need to have a separate multi-DLL build. The current build should have a memory footprint very similar to Google Chrome browser.

Thanks

You can check the total system available memory instead. The memory usage in task manager is misleading. The main difference between our product and Chrome is how we load the native DLLs and how this plays out in Chromium browser engine's multi-process architecture.

Chrome uses Windows to load DLLs and Windows loads DLL directly from the disk. Since Windows knows this is a DLL backed by the file system, Windows will load only one copy of this the read-only section of DLL (which usually contains the code) and memory usage of that section is not counted in each process. The writable section of the DLL (which usually contains data/variables) does count and is duplicated in each process. So for example, if Chrome loads one DLL and the DLL has 50M code and 20M data and there are 3 Chrome processes, the total memory amount you see in the task manager will 3 Chrome process using 20MB each.

In our product, the native DLLs are embedded in our .NET DLLs (this is a huge advantage of our product so that you do not have to deal with native DLL dependency and versioning issue). As a result, we must load the native DLL into memory first and then load them from the memory. However we use the same optimization Windows loader uses: we only load the read-only section once in the whole system and share them between all child processes. Nevertheless, because Windows is not aware of this, the read-only section will be counted in each process by Windows in task manager. So for exactly the same scenario as above, you will see 3 EO child process with 70M (50M + 20M) each, not 20 each. This does not mean they use 210M together. They only use 50MB + 20M * 3 = 110M together. The real memory cost of each process is still only 20M in this case even though the task manager will show 70MB.

Once the DLL is loaded, pretty much the controls are handed over to the native DLL ---- and this part is 99.9% identical between EO.WebBrowser and Google Chrome browser since they are built from the same source. We do modify the code in order to seamlessly integrate it better with .NET. But the impact of such minor modification on memory footprint should be negligible. As such the two should have almost identical memory consumption at system level.