Rank: Member
Groups: Member
Joined: 2/10/2014
Posts: 17
|
Hi,
We are checking the performance of the WebBrowser control. For this, we are testing a page loading around 200+ js files. We have observed that, the time taken to load all JS files is going min. 3 seconds and the caching is not working as expected. i.e. Second time when we load that same page, then Browser control is taking same amount of time (some times more time also). We have enabled caching at the time of launching the application and we see the catch folder is created when the application is run. Any thoughts on this is highly appreciated.
Wishes,
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
3 seconds for 200+ js file is actually not too slow. So I am guessing that while the caching is working correctly, it might not have a significant impact on your particular scenario. One case this can be true is if all the files you are trying to load is from a local file system instead of a remote network. In this case it doesn't make much of a different for the loader to load a file directly from the local file system, or to load it from its cache, which in fact is just a different file in a different folder. In fact in that case caching might make it even slower since the additional bookkeeping maintained by the cache.
EO.WebBrowser is based on Chrome, so it should have roughly the same performance as Google Chrome browser with cache enabled. You can try to use our TabbedBrowser sample to browser popular website and you should see its performance is similar to Chrome browser. One difference between us and Chrome is that we deliberately reroute many messages through the main UI thread in order to trigger the corresponding event in the main thread so that your event handling code does not have to worry about threading issues. As such if your main thread is very busy, then it can slow down the performance. The message rerouting should not cause any visible difference for a typical Windows application because if somehow you do a lot of work in the main thread and keep the main thread busy, then your UI would be sluggish to user input which would not be acceptable anyway. For a typical UI application, the main thread is almost always sitting idle waiting for input. In that case the message from EO.WebBrowser comes in and out the main thread very quickly and does not cause any significant delays.
I would recommend you to test with typical websites instead of extreme non-typical testing such as pilling up hundreds of script files. This is because, first, for a real website it is unlikely to use that many JavaScript files. Second, the final performance when browsing real website relies on a lot of factors: network loader, HTML parser, JavaScript engine, cache manager, rendering engine, etc. The browser engine as a whole is intended to be used on such "mixed" scenario and it is optimized that way. So it doesn't make much sense for you to try to gauge the performance just by measuring loading/parse JavaScript alone.
Thanks!
|