Welcome Guest Search | Active Topics | Sign In | Register

RunDLL32 and Memory Footprint of EO.WebBrowser Options
MIke1999
Posted: Monday, April 21, 2014 2:29:12 PM
Rank: Newbie
Groups: Member

Joined: 4/21/2014
Posts: 1
We are evaluating EO.WebBrowser (vs. other packages, like cefSharp) to see if it's a viable solution for what we are looking for.

However, upon testing a very basic winform that uses EO.WebBrowser to pull up a simple, javascript-enabled page, we're seeing some troubling things in the process list in the Windows Task Manager.

First of all, the app seems to be spinning up a number of RunDll32.exe's upon first opening a new winform that contains a EO.WebBrowser control. But the more concerning thing is that not all of them seem to get cleaned up (or at least, not all of them seem to get cleaned up right away). We left the application up and running, and continued to keep opening and closing a new dialog box on a regular basis, and we found that the count of RunDll32 EXEs would range from 2 to 5. But it *never* got below 2... and at 100MB per process (of private working set memory), it's basically eating up an additional 200MB of system RAM.

Moreover, our app process itself stays at around 75MB.

As a point of comparision, CEFsharp stayed at around 25-30MB total with our app's process, and never spun up any additional processes, so it's total footprint stayed at 25-30MB.

Seeing that the total footprint of our app using EO.WebBrowser hovered at around 275M (a 9X difference!) and sometimes went as high as over 1/2 GB of RAM, we're wondering if we're doing something wrong, since it seems unlikely that two packages that more or less should be doing the same thing (e.g. providing a .NET winform wrapper around the chromium framework) would have such vastly different memory footprints.

Please advise. thanks!
eo_support
Posted: Monday, April 21, 2014 2:54:16 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

The number of rundll32 process you observed is normal. We have a multi-process architecture that is very similar to that of CEF3 and Chrome. Usually there is a "render" process that is responsible for rendering a page (so if you have two pages then you will get 2 render processes), a GPU process that is responsible for handling all GPU related calls, and a "main" browser process that does everything else and coordinates the GPU and render processes. The difference between us and other solution is, we run the main "browser" code outside of your .NET process, where as others runs inside your main process. As such usually you will have at least two rundll32 process, one for the "browser" process and one for the GPU process.

We are aware of the memory footage issue. It has to do with how we load native code. All our native code are packed inside a single .NET dll (EO.WebBrowser.dll) and we dynamically load them from memory. For other solutions, you have separate DLLs and they are loaded from disk. When a DLL is loaded from disk, the file is directly mapped into the process's address space by the OS and it does not have to allocate all the memory for all the code in the DLL up front, so they do consume less memory. The amount of memory consumed/saved is directly related to the DLL file size, since Chrome's code base is huge, so you observed a significant difference.

We are thinking about a number of options that can alleviate this problem. One way is to make all process to share the same copy of the code block, that way you will have a one time memory consumption that is directly related to DLL size but as it does not grow based on how many page you load, so it might be an acceptable solution. Another solution of course, is to ship with separate DLLs, which is something we are hesitate to do because a lot of users love our single .NET dll deployment since it's very easy to maintain and deploy. However it might be possible for us to have two different distribution: one with a single DLL and one with multiple DLLs. Hopefully we will be able to get at least one of these two options implemented soon.

Thanks!
fm
Posted: Monday, May 12, 2014 3:56:41 AM
Rank: Newbie
Groups: Member

Joined: 7/2/2013
Posts: 7
Hi, do you have any update about this? Any ETA?
eo_support
Posted: Monday, May 12, 2014 10:52:31 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

We will most likely implement to have all processes to share the same copy of the code block. Unfortunately we are still in the early stage of implementing this feature. So currently we do not have any ETA yet. Sorry about it!

Thanks!
Craig Oliver
Posted: Monday, July 7, 2014 2:15:13 PM

Rank: Advanced Member
Groups: Member

Joined: 7/7/2014
Posts: 60
fm wrote:
Hi, do you have any update about this? Any ETA?


We too are evaluating this. We're currently using Awesomium, but the EO browser has far fewer issues and appears to work better. The memory usage does seem to be a potential issue.

Background: we're using a Windows (and iOS for the iPad) as a wrapper for our web-based software to handle secondary authentication, specific upload processes, etc. We've found a few memory issues in a few JS libraries, and they can cause massive memory allocations that eventually break the browser wrappers. While we're working on the web client side of things, the current Awesomium wrapper deals with the memory issues a bit better it appears.

We've replaced the Awesomium with EO and are really pleased: managed to remove a lot of workarounds and greatly simplify a fair amount of code. The only real remaining issue is memory usage (the Awesomium wrapper will handle about 50+ encounters whereas EO currently seems to break at about half that due to the memory issue).

thanks,
Craig Oliver
eo_support
Posted: Monday, July 7, 2014 2:31:16 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi Craig,

Thanks for posting in the forum. Unfortunately we do not have an ETA on this yet. As you already know, other users have also noticed this issue so it is definitely a priority for us. However there are multiple factors. Except for what's mentioned previously, comparing to many of our competitors we are also based on much newer code base of Google chrome, which results in bigger memory foot print since there is simply more code in the newer versions. There is no way for us to completely eliminate those since it is crucial to a lot of our users to have an up to date browser engine. We are working on a number of options, but it would be more like a gradual optimization process rather than a clear cut "done and close" issue.

Thanks
Craig Oliver
Posted: Monday, July 7, 2014 2:53:16 PM

Rank: Advanced Member
Groups: Member

Joined: 7/7/2014
Posts: 60
Thanks. Hopefully we can work out the web client / javascript issues on our side & make this a non-issue. As you seem to adhere closer to Chrome, it appears we may even be able to remove at least 1 JS library, the one causing the most damage in terms of memory leakage.
eo_support
Posted: Tuesday, July 8, 2014 11:45:03 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
I am glad to hear that you can optimization some on your side as well. That would be great. Please be rest assured that we are working hard on our side too!
Fabien
Posted: Tuesday, July 22, 2014 10:30:04 AM
Rank: Advanced Member
Groups: Member

Joined: 7/21/2014
Posts: 129
Hi,

We are currently evaluating your EO.WebBrowser component too. Your component is great, but we encounter the same high memory usage (100 MB by rundll32 process).

Can we make something to reduce this memory usage until you solve this issue?

Thanks
eo_support
Posted: Tuesday, July 22, 2014 11:20:34 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

Currently we have a separate DLL build that can reduce the amount of memory it uses. Instead of just a single .NET DLL, this build contains one .NET DLL and multiple native DLLs. The separate DLL build uses less memory but have the following disadvantages:

1. The total DLL file size is bigger than the single DLL build;
2. You must redistribute multiple DLLs intead of just one, and you can not mismatch different DLLs from different build;
3. We do not officially support XP. However it has been reported that the single DLL build works on XP, while multiple DLL build does not;

We do not publish the separate DLL build since most users prefer the single DLL build. However we can send you the download link if you would like to give it a try. Please keep in mind because we use newer Google Chrome code base, the memory foot print is always bigger than older version ---- even with the separate DLL build. This is because newer version of Chrome uses a multi-process architecture that is more stable and secure than the single process version (for example, if one page crash your hosting process won't crash), but one of the downsides of this architecture is its relatively high memory consumption. You can observe the same with Google Chrome browser.

Thanks!
Fabien
Posted: Tuesday, July 22, 2014 11:39:53 AM
Rank: Advanced Member
Groups: Member

Joined: 7/21/2014
Posts: 129
Thanks for your quick reply!

The first two disadvantages are not really for us with the way we operate, by cons, non compatibility of XP is dramatic :-(

Unfortunately a significant percentage of our clients are still working on XP, so XP support is mandatory for us ...

I use the latest version of Google Chrome (36.0.1985.125 m) and memory consumption is actually higher but the chrome.exe process are around 50 MB, which is still two times lower memory consumption found for EO.WebBrowser.

I'm sure you have ideas to improve the memory consumption while keeping a single DLL XP compatibility. Angel
Craig Oliver
Posted: Tuesday, July 22, 2014 11:52:52 AM

Rank: Advanced Member
Groups: Member

Joined: 7/7/2014
Posts: 60
eo_support wrote:
Hi,
...
However we can send you the download link if you would like to give it a try.
...

Thanks!


If we could, and as we (finally!) stopped supporting XP, we'd like to try the multiple DLL version.

thanks!
Yannou
Posted: Monday, July 28, 2014 10:33:50 AM
Rank: Member
Groups: Member

Joined: 7/28/2014
Posts: 10
Hello,

I'd like to try the multiple DLL version aswell can you provide me a link for downloading this version ?

Thanks
eo_support
Posted: Monday, July 28, 2014 10:45:57 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi Yannou,

Please see your private message for the download location of the multi-DLL build. You will need to change your application reference to use the EO.WebBrowser.dll in that build and make sure all other DLL files are in the same directory.

Thanks!
John
Posted: Monday, July 28, 2014 2:34:51 PM
Rank: Newbie
Groups: Member

Joined: 7/28/2014
Posts: 1
I'm evaluating the product as well. It looks like a good fit for us. My only concern is the memory usage. Can I get the link to try out the multiple dll verson as well?
eo_support
Posted: Monday, July 28, 2014 5:22:32 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi John,

Please see your private message for the download location of the multi-DLL build.

Thanks!
Yannou
Posted: Tuesday, July 29, 2014 4:16:22 AM
Rank: Member
Groups: Member

Joined: 7/28/2014
Posts: 10
Hello, thanks for sending us this build.
It is way more efficient and attractive to us.
Memory consumption is divided by 2 ... :)
Fabien
Posted: Tuesday, July 29, 2014 4:20:40 AM
Rank: Advanced Member
Groups: Member

Joined: 7/21/2014
Posts: 129
Hi,

Can you please send me the link too? I now it's not compatible with XP (any chances for the multi DDL release be compatible with XP?) but if the memory consumption is divided by 2, It's worth it to test!

Thanks.
eo_support
Posted: Tuesday, July 29, 2014 8:54:47 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

You can download the multiple DLL build here:

http://www.essentialobjects.com/builds/EO.WebBrowser.SeparateDLLs.3.0.71.zip

Please note that the exact amount saved would depend on the page. Also we are working on implementing similar mechanism for the single DLL build. Once that is implemented, multiple DLL build will no longer be needed.

Thanks!
PhilipT
Posted: Monday, August 18, 2014 10:17:23 AM
Rank: Advanced Member
Groups: Member

Joined: 2/15/2014
Posts: 52
Hi,

Is there ETA for this yet?

Thanks.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.