-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance degradation in the flex function expandItem() #1227
Comments
Hi Bharath,
I will spend some time on this in the 2nd half of September, aiming to
solve that before the next release.
Greg
…On Mon, Aug 14, 2023 at 9:11 AM abharath23 ***@***.***> wrote:
Hello All,
We are seeing a performance degradation in the flex function expandItem()
(compared to flash) when we iterate a list with a huge count (5000+ items).
It takes around 30min for an array size of 5000 nodes and ~2min for 1000+
nodes. Hence browser shows the state as hanging but internally it is
looping through the children (if we wait for a few minutes, it will get
loaded for 1000+ nodes but not support 5000+ though). Internally it goes to
list iteration and we believe that is causing this issue.
Can this be looked into for the next release as a priority?
Thanks,
Bharath
—
Reply to this email directly, view it on GitHub
<#1227>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABC3PVTHR4NWGWD4E25VUBTXVHFQRANCNFSM6AAAAAA3PIWJHM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Thanks Greg, I was planning to send you a separate note on this.
Hope things are fine at your end and doing well.
Regards,
Bharath
On Mon, 14 Aug 2023 at 12:45 PM, greg-dove ***@***.***> wrote:
Hi Bharath,
I will spend some time on this in the 2nd half of September, aiming to
solve that before the next release.
Greg
On Mon, Aug 14, 2023 at 9:11 AM abharath23 ***@***.***> wrote:
> Hello All,
>
> We are seeing a performance degradation in the flex function
expandItem()
> (compared to flash) when we iterate a list with a huge count (5000+
items).
> It takes around 30min for an array size of 5000 nodes and ~2min for
1000+
> nodes. Hence browser shows the state as hanging but internally it is
> looping through the children (if we wait for a few minutes, it will get
> loaded for 1000+ nodes but not support 5000+ though). Internally it goes
to
> list iteration and we believe that is causing this issue.
>
> Can this be looked into for the next release as a priority?
>
> Thanks,
> Bharath
>
> —
> Reply to this email directly, view it on GitHub
> <#1227>, or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ABC3PVTHR4NWGWD4E25VUBTXVHFQRANCNFSM6AAAAAA3PIWJHM>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APX3ZHNPCYX5NITH7QP7DY3XVHGBBANCNFSM6AAAAAA3PIWJHM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Thanks,
Bharath.
|
Hi @greg-dove Have you been able to get to this ? |
Sorry @abharath23 no I did not yet, I was unable to find enough free personal time during last 6 -7 weeks. I do have a couple of days on weekends during November that I have set aside to look into this, starting weekend of Nov 11. |
fyi I have begun work on this, but I am still working on setting up to create a test app for reproducing the issue. I expect to be in a position to repro, test and work on the actual issue next weekend. |
Where is this function?
The only place I see a function named “expandItem” has the code mostly commented out.
Bad performance like that seems most likely caused by forced reflows.
… On Nov 12, 2023, at 7:41 AM, greg-dove ***@***.***> wrote:
fyi I have begun work on this, but I am still working on setting up to create a test app for reproducing the issue. I expect to be in a position to repro, test and work on the actual issue next weekend.
—
Reply to this email directly, view it on GitHub <#1227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADAVQEN6P2SRNOHAKGVD63YEBORXAVCNFSM6AAAAAA3PIWJHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBXGAYTCMZUHE>.
You are receiving this because you are subscribed to this thread.
|
@Harbs this is in mx emulation code, in AdvancedDataGrid (and/or perhaps Tree). I am familiar with this problem in terms of having observed it myself in the past. |
@greg-dove Is there an update on this issue and tentative ETA to get the fix? |
Hi Bharat, I haven't had very much free time to work on this in recent months, I'm afraid. I did send you an email in November suggesting I might get to it at the end of January, but things changed and I was unable to do so. I will spend a day on it this coming weekend. Then I have a couple more weekends from mid April that I can continue to look into it. I'm guessing it will take a couple of days once I can repro the issue. So best I could suggest at this point would be end of April. It would really help if your team can provide an isolated example with some mock data so I can avoid delays with trying to reproduce the issue, because I need to do that locally in order to work on it. I do remember the general nature of the issue, but being able to repro it is probably half the work, and your team is best placed to help with this. Or if that is not possible, please refresh my memory with a detailed description of the example (it's perhaps easier to send that directly to me). For example, I can't remember if it was XML data or some other non-xml hierarchical data (or if the issue is present with both). It sounds like 1000 child items would be a good test case. Also was this in Tree or AdvancedDataGrid (or both) ? thanks - Greg |
@abharath23 just a quick follow-up for now. I spent a day on this, integrating a large swathe of emulation component monkeypatches in preparation for working on this. There was more work to this than it would be easy to assume, because they needed to be split across different modules (swc lib projects) and also because they weren't all compatible as-is with the swf target by default. However I do now have that compiling, with the patches in place. I will need to do some more general testing of this local branch and then I will push changes to a remote branch. I'll try to get that done after hours during my week if I can, but can't guarantee that - it may not be until I start to work on the repro of the issue. Anyhow, my best case estimate is that (unless someone in your team can provide me with an isolated reproduction of the issue) I will probably need the weekend of April 13 to try to repro the issue you described, and then perhaps the following weekend to address it. I'll keep you posted. |
Quick update: It turned out that I have been unavailable the last couple of weekends, and the current weekend is likewise busy with other tasks. I have the weekend of May 4th/5th clear at this point and plan to work on this issue then. My first focus will be trying to repro the issue. |
quick update: I have made a start in recent weeks with a branch to prepare to work on this, but won't have time to continue to work on it until the weekend commencing June 2. |
Hello All,
We are seeing a performance degradation in the flex function expandItem() (compared to flash) when we iterate a list with a huge count (5000+ items). It takes around 30min for an array size of 5000 nodes and ~2min for 1000+ nodes. Hence browser shows the state as hanging but internally it is looping through the children (if we wait for a few minutes, it will get loaded for 1000+ nodes but not support 5000+ though). Internally it goes to list iteration and we believe that is causing this issue.
Can this be looked into for the next release as a priority?
Thanks,
Bharath
The text was updated successfully, but these errors were encountered: