Accessing a Dictionary containing Vectors results in String allocations on iOS.

[PrimaryFeather]

Problem Description

On iOS (only), assigning a property from a flash.utils.Dictionary, where the property type is a Vector of any non-primitive type, results in at least 3 hidden string allocations, according to Scout.

This was tested with the latest AIR Beta SDK (version 26.0.0 build 112), and several iOS devices using iOS 10.3.2. On Android and Desktop, there are no allocations.

Adobe Tracker Issue: https://tracker.adobe.com/#/view/AIR-4115729

Steps to Reproduce

The class StringAllocationIssue.as constitutes a minimal sample that showcases the problem by accessing a Dictionary once per frame, and StringAllocationIssue.flm shows the analysis of this application on an iPhone 6S. You'll see that once per frame, there are three String allocations; those do not happen on Android or Desktop.

Known Workarounds

When using an Array instead of a Vector, there are no allocations.

[hardcoremore]

@ajwfrost Andrew, this is also important one. Is there a hope for this to be fixed?

[ajwfrost]

Yes we can look into this one, I've added it to our internal tracker at AIR-256

[hardcoremore]

Awesome,

Thanks so much Andrew.

Regards,

Caslav

[hardcoremore]

Also this is happening for Vectors of non primitive type as well. It does not have to be Dictionary.

[jimmymjing]

I'm facing the same issue.

[ajwfrost]

So we've found the reason for these string allocations.. basically the AOT compilation needs to look up the traits of the vector of whatever object type is being referenced here, and it does this by creating the fully qualified name of the type and then doing an internal string-based query in the domain.

We're going to see if there's a different way that we can access the traits here that will avoid the string allocations; as a fallback option though, these strings should be being cached/reused so that they are created at most once for each vector type!

[PrimaryFeather]

Thanks so much for looking into this, Andrew! It's great to finally know what's happening here – and caching that String seems like a sound solution to me.

[hardcoremore]

Awesome work Andrew!

So that is how much Adobe was lazy, at a minimum they could at least just use one string for each type but they were too lazy to even do that. Anyway this will save a lot of GC collection calls. Thanks again!

[hardcoremore]

Hi @ajwfrost,

Any news about this issue?

Regards,

Caslav

[ajwfrost]

@hardcoremore this is on our current list - we did start looking at it so should have an implementation in there soon..

[hardcoremore]

Awesome, thanks @ajwfrost.

[jimmymjing]

@ajwfrost @hardcoremore
Hello, I'm still facing this String allocation issue on iOS. Is there any news? thanks so much!

[hardcoremore]

@jimmymjing this was fixed I think. But I didn't test it. Do you see one string allocation per Vector/Dictionary or multiple?

[jimmymjing]

@hardcoremore I just read through your post on Starling's forum and I also thought it was fixed. but I'm seeing a lot of string allocation with DispatchEventWith() function call in scout.
Here's the screenshot: https://ibb.co/DKzCdWR

[ajwfrost]

Hi all - I just spotted this thread again, thought this had been closed...
So we did update the code so that the original issue is fixed: there will be a string allocation when the first vector type is generated but subsequent accesses should reuse the strings.

It sounds like there are other places where string allocations are happening though. Don't forget that anywhere you create a String object there will be an allocation, so events are quite big culprits for this. Internally the character memory that holds the string is handled fairly efficiently, so e.g. the character memory holding "enterFrame" will be set up once, but then each event that's created will create a new String object that refers to this.

I don't think that's the most efficient thing in the world - even the fact that every frame is sent a newly created enterFrame event seems a bit daft to me. So we can look a bit further into efficiency savings here: please let me know of any particular issues you're seeing where you think that string allocations should be unnecessary!

thanks