Ext.NET 4.7.1 uses more memory on client than old version and rendering is slow (on IE11)

[claudiacostaors]

Hi,
we are porting our application from EXT.NET 1.7.0 to version 4.7.1.
We must support IE11, we unfortunatly noticed that:
- the application with the new version is using more memory on the client (IE process), almost 3 times more than version 1.7.0.
- the rendering seems to be slower

We also noticed that those problems also navigating the examples, see images attached (we clicked 25 samples, in "GridPanel" section):
- Samples_1.7.Memory.png
- Samples_4.7.1.Memory.png


Is there a way to reduce memory usage and speed up rendering?

Thank you so much

Claudia

[fabricio.murta]

Hello @claudiacostaors, and welcome to Ext.NET forums!

While we know there's always room for improvement, we're talking about a long difference between versions, there's just more code running, new themes, more components, existing components with more events and support for newer browsers as well as mobile and touch-driven devices, and so forth.

There's not much really that could be done to keep the new features and recover the memory and CPU footprint of version 1.

Hope you understand.

[claudiacostaors]

Hi Fabricio,
I understand that there are more features than 1.7 version, but for us is a huge problem, we can't release our application: the memory reaches 1 GB just navigating few functionalities.

There also a problem with rendering in IE11, the user have to wait too long for the rendering, with the 1.7 the rendering is faster, do you have any suggestion?

We did a very difficult job in porting from 1.7 to 4.7, but if the application performances are worst we can't proceed...
We were almost ready to buy the licence with Premium support, but if we don't find a solution we can't.

Just few information:
- With Chrome the performances are better, but we must support IE11, the users of our application cannot use other browser that IE11
- We have an application wich uses ExtJS 6.6 version, but we didn't notice any problem with memory or rendering.

Do you have any idea or hint?

Thank you so much.

Claudia

[fabricio.murta]

Hello @claudiacostaors!

Thanks for your interest in acquiring Ext.NET license, we really appreciate it; and the efforts already made into migrating your application to the latest version 4.

Can't say much without knowing what exactly you are comparing. A grid panel, or a form? There's not even a way to compare if using charts for instance, which is a feature absent from version 1.

Ext.NET uses but the same Ext JS 6.6, there shouldn't be much more in usage between both, but there should be some, yes, as Ext.NET introduces some extra features and also homemade fixes to issues raised here in the forums that Sencha didn't answer to.

Your memory comparison using examples explorer may not be really fair. Each example is open in an iframe, which is basically a new browser tab. If you open a single charts example, you'd likely to notice a memory usage worth 10 v1 examples; charts is not a feature at all in v1 to be compared. There's no memory leaks (at least obvious ones); if you don't close the tabs, they are literally kept open for quick switching back. You can unload the tabs as they are switched away in order to free up that memory, and load them back when selected again. So if you're getting 1GB memory readings in your actual application, there are likely ways in improving it.

I didn't see a noticeable degradation in performance while trying to open examples v4 in IE11. But I was unable to open Ext JS 6.6 examples in IE11 at all. Maybe if you have a particular example you noticed a weird degradation, it would help get a measure if you pointed it out.

That said, there's not much we can do to take Ext.NET 4 down to the level it was in v1 due to the reasons pointed in our previous post. But I still believe there are ways to explore the new features to get more out of Ext.NET 4 after a migration from v1 and get affordable performance even for legacy hardware; but it would require extra efforts nevertheless to identify and mitigate the issues.

Well, hope this helps!

[claudiacostaors]

Hi Fabricio,
thanks for your response.
We are comparing our application and also the samples.
Our application is complex, so we are preparing a simple application with both version which can be used for comparison, so we can gave you more details (we are not comparing charts).

Meanwhile, I compared performances between 1.7 and 4.7 version using IE11 Profiler, for the sample "Simple Array Grid".
- https://examples4.ext.net/#/GridPanel/ArrayGrid/Simple/
- https://examples1.ext.net/#/GridPanel/ArrayGrid/Simple/

We noticed that 1,7 sample is more responsive than 4.7 version.
For examples we noticed that "Script Evaluation Time" is:
- 1.92 seconds with 4.7 version
- 234.65 milliseconds with 1.7 version


The profile gives plenty of useful information for the comparison.
I attached some useful information

- PerformanceProfiler_Img_1.7.png:
- PerformanceProfiler_Img_4.7.1.png:
- Computer.png:
- IEVersion.png:


May you give us some feedback on the sample performance?

In general we noticed that with IE11 performances and memory usage is worst than Chrome, did you noticed the same behavior?


Thanks a lot

Claudia

[fabricio.murta]

Hello @claudiacostaors!

Your profiling results are consistent. That's what to expect between Ext.NET 1 and 4.

IE11 has not been updated for a while, at least not new features/optimizations; probably if anything, only security fixes. So the better performance in chrome is well expected and yes, I notice it here as well. If you are unable to upgrade your clients from IE11 and the application is not scaling for the legacy systems, maybe it is not a good idea to upgrade Ext.NET at all. Would be like trying to install windows 10 on non-NX capable CPU machines.

The same example (standalone) you tried in a 5-sample run gave an average, per browser:

- IE11 11.345.17134.0: 4s876ms
- MS-Edge 42.17134.1.0: 1s770ms
- Firefox 63.0.1: 1s242ms
- Chrome 71.0.3578.98: 1s90ms

So clearly IE11 is in a loss here, even from its relative Microsoft browser (which, by the way, has been said to be changing to chromium engine this year).

Hope this helps!

[claudiacostaors]

Hi Fabricio,
I'm so sad to hear that you doesn't suggest the upgrade, for us this is a huge problem...
Unfortunately we can't use browser different from IE11. Do you know if there are some other cases where people noticed performance issues on IE?
The test response times that you reported include also network time?

I try to ask you some questions that could be useful to us

- Is there a way to reduce the js sent to the client (for example, remove unused classes, see also https://forums.ext.net/showthread.ph...ll=1#post18748 , see comment “With the v1.0 release we're planning to include functionality to allow for further combining and configuration of the .js resource files as well as potentially break apart the .js resource files to exclude unused classes. That should help reduce some weight and further improve performance.”)

- Is there some Ext.NET configuration that could increase performances ? (see http://docs.ext.net/d4/d9c/class_ext...al_config.html )

- Is there a way to find the mapping from Ext.NET and ExtJS class? We are asking this because we are thinking to develop a tool which identify ExtJS used classes (starting from Ext.NET) so we can reduce in some way the js sent to the client.

Thanks a lot

Claudia

[fabricio.murta]

Hello, Claudia!

I will try to respond every of your questions below with as many details as I can think about. Hope the reading proves helpful!

Do you know if there are some other cases where people noticed performance issues on IE?

It's been a while, some years maybe, since I last heard about experience on IE with Ext.NET, so while there were, yes, talks about IE compatibility with Ext.NET, the most troublesome ones were fixed by the time. And those specific fixes for IE11 might also have helped to decrease response times with the browser -- but they were required nevertheless.

The test response times that you reported include also network time?

Yes, they include network overhead as I did the tests against the live examples explorer. I have an average round-trip to the server of 120-150ms from where I am, and the EE does not use CDN optimized paths to resources at all, but from 2nd request onwards, most become cached. It also includes SSL encryption in the overhead.

Is there a way to reduce the js sent to the client

Yes, and no. For instance, if you don't use charts, Ext.NET won't load the resources required for them unless explicitly specified (in cases the developer wants to build charts dynamically from client-side or post-load events/calls). Some other Ext.NET-specific components won't load unless used/specified either. But most of the core functionality of Ext JS, due to issues in the past, must be loaded at once.

If you are not going to run the webserver on the company's intranet, or if you are having the customers access the server all across the world, you can instruct Ext.NET to use CDN as the endpoint to load the resources from. This would allow faster network transfer times as the resources would likely be hosted "closer" to the customers.

If you are running the service from the company's intranet to clients constrained within the same company's intranet, CDN will probably not help much, unless you have issues on the server being too busy to answer requests even for the intranet.

This usually only improves the first load though, as browsers will cache the js, css and image resources throughout a single Ext.NET version life (and user browsers' cache). If Ext.NET is upgraded, it ensures to let clients know the version has changed so that they download the fresh version of scripts. The following loads, even of other pages, would have, for example, the ext-all-js script already cached, so that shouldn't become a network bottleneck. I don't think this can give so much an advantage to IE browsers if the script to parse was smaller. Besides, the overhead to load the different scripts might kill the advantages of loading a single one.

Is there some Ext.NET configuration that could increase performances?

Well, there are.

- SourceFormatting is used for debugging. Disabling it would allow code to be output minified, so less data thru the network channel. This only affects the dynamic script run by the pages (the panels you set up, grid to load, direct method/events responses, and so on). This is disabled by default.
- ScriptMode is also used for debugging, but affects how the base scripts are offered to the browser. Being Release by default, it offers minified files instead of the formatted ones (like extjs-charts-all, extjs-all, ext-all, and so forth). If Debug, then the non-minified files are offered.
- Theme usually the older themes are easier on the browser than the modern ones, but I can't say how the extent of a performance gain to the visual price would be.
- InitScriptMode could save you a further request at load time by setting it to Inline. The default Linked means it will offer the dynamic page script as a separate resource, thus another request would be needed to fetch the script. I don't expect a noticeable increase in performance with this, though.
- Disabling the Aria related checks might also improve performance overall.

Is there a way to find the mapping from Ext.NET and ExtJS class?

Yes. Every Ext.NET class has a InstanceOf and XType property that reflects to the corresponding full Ext JS class name and its alias xtype, respectively. You can draw a C# application to step thru Ext.NET classes fetching the value to identify the Ext JS entity.

Premium subscription grants access to Ext.NET source code. This would allow you to draw a parser or even adapt Ext.NET to your needs. For instance, you could even strip down a version of ext-all and make a selection of resources you'd want to load to given pages, like "ext-accounts", "ext-listings". But this would require solid C# skills to handle modifying the Ext.NET sources and keeping between upgrades to keep the code up-to-date. While we don't offer per-customer customization in code, we'll be willing to help here in the forums with questions you have about extending Ext.NET.

Ext.NET sources are offered under the git DVCS, and distributed via a private GitHub repository.

Alright, I think this answers the questions you made here, let us know if I skipped any. Hope this helps!

[claudiacostaors]

Hi Fabricio,
first of all thanks for your kind and comprehensive response.

We tried to configure Ext.Net as you told us, but we didn't notice significant differences in performance and memory.

Our application is an Enterprise Application for Banks and it's used in intranet, so the CDN suggestion might not
give us performance improvements even if it's an useful information we used to do the experiments below.

We are doing some experiments to limit ext-all.js size
- we implemented a ResourceManager which is able to serve a different version of ext-all.js
- we created a minimal version of ext-all.js with sencha command, but we noticed that extnet-all.js fails
because it needs some ExtJs classes that we stripped out, so
- we manually fixed extnet-all.js removing the unused code.

I'd like to ask few other questions:
- How do you would make the minimal "selection of resources" to include in a ext-all.js?
- Is there a way to reduce extnet-all.js too?
- May you give us more details about IE11 fixes that you suspected had decreased performances?
- May you give us more details about the problems that you encountered when you decided to load most of Ext JS at once?

We think that we could adapt Ext.NET to our needs, but now we can't buy the license with Premium subscription because
we need to be sure to find the solution for performance and memory problems.

Our current analysis indicates that most of the performance issue comes from script execution and possible CSS class resolution.
The current approach we are exploring consists of reducing the script execution time by reducing the number of classes
that need to be parsed and loaded into memory. However we have noticed that the number of CSS classes used by the
framework has grown a lot from past versions. Is there a way to optimize the style calculation on the browser by reducing
the resolution complexity of the CSS, maybe reducing cascading by pre computing more specialized classes?


Thank you so much!


Claudia

[fabricio.murta]

Hello @claudiacorstaors!

I will try to briefly answer all your questions here. Point some you feel needs more elaboration on:

- How do you would make the minimal "selection of resources" to include in a ext-all.js?

Well, one way to do that would be by trial-and-error, but there's no telling when that would fail. Especially if you have dynamic code (that creates screen components on-the-fly). But if you just look at the component you use, then check in the documentation the class hierarchy, you might be able to get a good guess to start with.

- Is there a way to reduce extnet-all.js too?

There's no "included" way to do so (by changing a setting). But if you are into modifying the file, sure you can reduce it, but you would be losing bug fixes and features that are exclusive to Ext.NET. What you probably don't want to strip off extnet-all, if you're willing to let the bugfixes go, is the specific AJAX code for Ext.NET core functionality.

- May you give us more details about IE11 fixes that you suspected had decreased performances?

I don't have any specific fix at mind. In general the fixes are there because IE lacked a feature and needed it treated a different way -- usually slower. Just check the code for Ext.isIE() and you should find IE-specific code therein.

- May you give us more details about the problems that you encountered when you decided to load most of Ext JS at once?

I am not the one who made that decision, so I can only tell by my experience. There is no feasible and reliable way to load the resources as-needed, as far as we could spend time to develop.

Is there a way to optimize the style calculation on the browser by reducing
the resolution complexity of the CSS, maybe reducing cascading by pre computing more specialized classes?

There is no way we know of. The scripts have builtin CSS styling references that are filled in every theme, so display of one or more components will break if you don't have these. Sometimes a component may reference a CSS from another component, so I don't believe there's an easy reduction in that aspect.

Hope this helps!