PDA

View Full Version : 4.1 Beta Performances



paipai
9 Jan 2012, 12:55 AM
Did you tried the 4.1 b ? how is it for you ?
I work 3 days to fix many problems to update my app in 4.1 beta (there still a lot of bugs, but I can use it). Now it does'nt work anymore with 4.0.7 but the result is slower (I don't run benchs, just using the app). It seems slower in all browsers.

How is it for those who test ?
Thanks for responses.

slemmon
9 Jan 2012, 7:09 AM
I can't get my two existing apps to load with 4.1 B1 with the existing bugs. Started sandboxing with a new app and got as far as I could reporting what I could along the way, but the bugs finally pushed me back down to 4.0.7.

But, I have high hopes for 4.1 B2. :D

scancubus
9 Jan 2012, 1:59 PM
What kind of bugs are you having? I have migrated our large app to 4.1. Been through a lot, feel free to post and we can figure it out.

slemmon
9 Jan 2012, 2:34 PM
Thx for any help you can offer.

A couple of bugs I reported on the bugs page already. One was when adding CSS dynamically (which my login window does, sadly) and having that in play breaks the login which has some persisting effects all by itself.

But, if I take that out, the forms are all empty. A height/width is there where the form fields and fieldcontainers once were, but they don't appear to be rendered.

And anywhere where there was a form field that is rendering its width is like 30-100 px where in 4.0.7 they were the width of the owning container (under anchor 100% layout setup).

slemmon
9 Jan 2012, 2:53 PM
In the second app I keep getting errors of 'el is null'. Seems to be when the viewport is instantiated and it's adding each component.

el.addCls.apply(el, arguments) * line 63823 in the Ext-all-dev-w-comments file

The cls being added each time is: x-docked.

lorezyra
9 Jan 2012, 5:20 PM
I uploaded 4.1.b1 to my server and tested my app... It seemed to break everything. I didn't want to waste much time troubleshooting it... especially since it's a beta. Under the beta, my "simple" login form failed to render and my application failed to startup completely.

I designed the GUI in Designer (XDS) and wrote the business logic when I was satisfied with the layouts. This is a CMS/blog manager that I have been developing since the ExtJS 3.1 days.

At this point, I'll wait for the general/stable release of 4.1 before uploading ExtJS to my server.~o)

gilfeather
10 Jan 2012, 7:56 AM
There does not seem to be any though toward backwards compatability. We had the same issue with even the most simple login screen not working. It will take us at least a week to get things working so/so. Some of this is to be expected given the amount of customizations that were required to the base ExtJs code while some of it is just plain poor development practices by Sencha.

That being said, it takes 1980ms (on a slow browser/hardware platform) to make the viewport visible under 4.0.7 and about 800ms under 4.1 b1. Given that out slowest platform is 6x slower than this that platform will go from 12 seconds to 5 seconds. Still not good but better. 2.1 was significantly faster but we were not attempting a pure JS solution for that.

mschwartz
10 Jan 2012, 11:36 AM
We have a shipping product that's been continuously developed for the past 3 years, first using ExtJS 2, then ported to ExtJS 3. When 4 came out, I looked at the issues to port to it, and we decided against it, and it didn't take much time/thought. The performance was not part of the consideration.

However, the existing ExtJS 3.x extensions we made and leeched from the forums were; porting those would add a significant amount of effort, cost, and time to the porting task. The number of overrides we made to get everything to work to our quirky standards would all need to be understood and ported.

I admit I haven't spent much time stepping through the ExtJS 4 code, or even really writing much for it.

I wanted to show what SilkJS could do, so I did an ExtJS 3 and ExtJS 4 demo and put it on github. The ExtJS 3 demo was a brief and smooth effort. The ExtJS 4 demo took a bit longer because I had to refer to the API and examples to get things even working. That's not a big deal, but my experience while running the code in my browser was almost painful. It crawled. It even made my browser appear to lock up for seconds at a time, or just run slowly (Google Developer Tools, too).

This is just a bit of constructive customer experience I'm relating above.

I do not mean to be critical of the 4.x effort in the least. They have some brilliant new ideas and ways to do things that prohibited legacy support (backwards compatibility). They felt starting fresh with an almost entirely new code base was the best strategy; I wish Microsoft would have figured out to do this with Windows many versions ago :).

I'm willing to suffer with the performance problems over the long haul. I mean, Sencha is using their own toolkit to do their client work so they must realize they have work to do to get it right. They're a bunch of really smart guys, and it's just a matter of time, IMO.

My big concern is that 3.x isn't going to get the attention it ultimately needs. 3.4.0 came out a long time ago, and I don't see much discussion of updates, fixes, and so on. Yet I have this legacy application that depends on 3.x, and I'm sure there are many others out there in the same boat.

You see, my Google Chrome magically updates itself. One day it's version 11.x, the next it's 12.x. One of these version changes, some browser detection and specialized code in 3.4.0 isn't going to work right with the new Chrome (or Firefox or IE or whatever), and I'll be flooded with customer complaints that their software stopped working (magically). I don't really care if they add new features to it, but it does need to be maintained. IMO.

rich02818
10 Jan 2012, 2:34 PM
Completely agree with the concerns about 3.4.x support as stated by mschwartz. I can't use 4.x in it's current state as performance is unacceptable. If Sencha fails to provide the necessary, timely support to 3.4.x they will effectively orphan a sizeable portion of their paying customer base. Very much hoping this does not happen...

joeri
11 Jan 2012, 12:37 AM
Given that we're just talking about bugfixes on 3.4.0, couldn't this just be a community effort? I don't see the need for Sencha to officially support that version if we're just talking about an override here or there. We could just have a thread listing a set of overrides that fixes all the known bugs with 3.4.0.

I've posted my overrides recently:
http://www.sencha.com/forum/showthread.php?160309-My-bugfix-overrides-for-3.4.0

On the other hand, this is where it really shows that ExtJS isn't a true open source product (developed by the community for the community). It would be a much more stable product if people could freely submit patches (overrides) and get them checked in to the core. Sencha could set up a CLA that anyone can sign to submit patches with appropriate copyright transfer.

tvanzoelen
11 Jan 2012, 1:37 AM
ExtJs 4.1 really breaks on every little tiny error. It took me two days to get my loginscreen running.
Now I see some things working but there are still problems.

For example. Somewhere in my code the hide() function of a button is called before the button is renedered (was possible in Ext js 4.0) then you got the most strange results like splitters not working, menu's broken. Things not related to the button.hide() error.

To get things working you must set firebug on break on every error, follow try catch and just fix every first error you encounter even if you think it isn't an important notification.

Even setting a width on a center region is a complete blow-up.

The use of Chrome developmenttools is useless in this proces, because you can not set that tool that strict as firebug.

alien3d
14 Jan 2012, 1:52 AM
Ya i'm still in legacy mode 3.4...1 years waiting for extjs 4 to speed process. but hold on first until stable release.

joeri
16 Jan 2012, 12:32 AM
The use of Chrome developmenttools is useless in this proces, because you can not set that tool that strict as firebug.

You can set chrome to break on every error: http://code.google.com/chrome/devtools/docs/scripts-breakpoints.html#js_exceptions

gilfeather
17 Jan 2012, 1:15 PM
The "upgrade/porting" process is fairly painful. That being said, if you ever get it to run again, performance is better on the older browsers. Our main screen went from 8-9 seconds load time on IE8 down to about 3 seconds. We had seen 4.0.7 load times down in the 6 seconds range but that was quite difficult to accomplish. The start up process had to be carefully managed/tweaked to make sure that rendering and layout happened as late as possible. Small code changes would cause rendering to happen early and then multiple layouts later the screen would finally show up. With 4.1b1 the sensitivity is gone. This performance level appears faster than the 4.1alpha release for our code base. Much of this I believe is attributed to the changes in the field layouts. Although I was somewhat dubious of the switch to tables from divs we were able to eliminate a significant amount of code in layout.component.field.text's sizeBodyContents routine.

The only issue we are seeing is extreme slowness in the setFieldLabel routine (300ms per label x 50+ labels). It seems that the doComponentLayout in that routine is not playing nice. We have worked around that issue for now but will go back and look at it at some point.

silcreval
19 Jan 2012, 12:42 AM
Same here, I eventually gave up with attempting to get a large app working with 4.1 there were just too many changes required. Layouts were way off, windows appeared blank and non-functional, etc, etc. It is very time consuming to fix these issues, and it takes time away from productive development.

tvanzoelen
19 Jan 2012, 1:08 AM
I think the Sencha team should have some examples of large applications at hand. In the development process the small things were working. But if I migrate from version x to y.... with my application (wich is big), I can see in one glance that there are bugs. The Sencha development team should have better test applications at hand.

But changing from 4.07 to 4.1Beta doesn't require much changes. Only finding the bugs was consuming time.
If the posted bugs are solved for the Beta 2, I think version Extjs4 is nearly there. And indeed the performance of 3.4 is still slightly better than 4.1. But 4.1 could be more stable if the latest bugs are fixed.

MrSparks
19 Jan 2012, 3:45 AM
Another suggestion for the Sencha team, would be to ensure that Dev team is using a mix of platforms to develop EXTJS.

i.e. The majority of the Dev boxes should be Windows based systems with various browser flavours, rather than just using shiny new Mac's as a primary Dev system.

Having a proper real world mix of systems would have identified the performance issues at the start of the EXTJS dev cycle rather than at the end of it.

LesJ
19 Jan 2012, 6:12 AM
The majority of the Dev boxes should be Windows based systems with various browser flavours, rather than just using shiny new Mac's as a primary Dev system.


Not going to happen... and I don't blame them. I have an iMac at home and a PC... the iMac is so much easier to use... my kids want another iMac =P~

paipai
19 Jan 2012, 6:39 AM
+1


Another suggestion for the Sencha team, would be to ensure that Dev team is using a mix of platforms to develop EXTJS.

i.e. The majority of the Dev boxes should be Windows based systems with various browser flavours, rather than just using shiny new Mac's as a primary Dev system.

Having a proper real world mix of systems would have identified the performance issues at the start of the EXTJS dev cycle rather than at the end of it.

MrSparks
19 Jan 2012, 11:39 AM
Not going to happen... and I don't blame them. I have an iMac at home and a PC... the iMac is so much easier to use... my kids want another iMac =P~

I would hope that Sencha didn't take the same view as you. Developing and Testing on a platform that is representative of your target market, is an absolute must and fundamental best practice.

LesJ
19 Jan 2012, 12:19 PM
Developing and Testing on a platform that is representative of your target market, is an absolute must and fundamental best practice.

This is where we disagree. If you feel more productive developing on the Mac or Linux, then why would you use a platform where you are less productive? It just doesn't make sense. You just need to test it on Windows.

As an example, Google developers require a special permission to use Windows (as they consider it less secure).

http://googlesystem.blogspot.com/2010/06/google-employees-need-permission-to-use.html

MrSparks
19 Jan 2012, 12:26 PM
This is where we disagree. If you feel more productive developing on the Mac or Linux, then why would you use a platform where you are less productive? It just doesn't make sense. You just need to test it on Windows.

Why, the main reason is because you can identify issues at the "start" of the product development life cycle rather than later on. It's just best practice. I understand that Dev's feel more productive on certain platforms, however a percentage of the Dev's need to take some pain, so that the customer doesn't.

mschwartz
20 Jan 2012, 4:48 AM
They can run Windows on Parallels or VirtualBox on their Macs. I'd hope a company that's into virtualization would know to do this (I have no doubt).