[
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)
