flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maurice Amsellem (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-33865) ConstraintLayout / LayoutElementHelper are memory inefficient (and slow)
Date Mon, 04 Nov 2013 00:50:17 GMT

    [ https://issues.apache.org/jira/browse/FLEX-33865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812545#comment-13812545
] 

Maurice Amsellem commented on FLEX-33865:
-----------------------------------------

> Because in the parseElementConstraints the array will be re-used == no memory allocation.
As far as I understand your code, the memory allocation saving is when you PASS something
in result, which means result is not null.
When result is null, that's the "normal" case, and in this case, they will be an allocation
(otherwise, where would the Array come from ) ?
Do you agree?

>This patch saves a lot of memory allocation, doesn't regress the speed and correct a bug
(trim)
I'm ready to improve the patch, but if memory improvements are not welcomed (and I understand
that : flex team might have other priorities) then tell me.

Benoit, honestly I have spend a lot of time on this issue already, so it's not about priorities,
but about relevance.  If it was about priority, I would have applied your patch, and moved
to something else.
My personal position is that optimization "for the sake of it" is not enough.  It needs to
provide measurable gains as "optimized" code is often more difficult to read and less easy
to maintain. 
But let alone my personal position,  as I am not the owner of the Flex SDK.

Since I am a new committer to Apache Flex, I have asked for advice from the team, on acceptance
criteria for optimization patches.
the answer from Justin is the following:

{quote}
"Does it improve significantly improve performance in real use cases for the majority of users
would be at the tip of my list. Calling a method 10,000 times is sometimes not a real use
case"
{quote}

So please, can you please provide some sort of "proof" that the performance is better, at
any level.
For example, can you show the GC figures ...

I am sorry, I can't do better than that.
Now, if a more senior member of the team thinks your patch is fine, then I would be more than
happy to have it accepted. 

Regards,



> ConstraintLayout / LayoutElementHelper are memory inefficient (and slow)
> ------------------------------------------------------------------------
>
>                 Key: FLEX-33865
>                 URL: https://issues.apache.org/jira/browse/FLEX-33865
>             Project: Apache Flex
>          Issue Type: Improvement
>          Components: Mobile: Performance, Spark: Layout
>    Affects Versions: Apache Flex 4.11.0
>         Environment: mobile desktop
>            Reporter: Benoit Wiart
>            Assignee: Maurice Amsellem
>              Labels: mobile, performance
>         Attachments: 0001-ConstraintLayout-optimizationsV2.patch, layout-1-desktop-memory.png,
layout-2-desktop-memory.png, layout-3-mobile-memory.png
>
>
> ConstraintLayout / LayoutElementHelper are doing too many memory allocation.
> it's really bad on mobile
> the attached screenshots were taken on desktop



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message