Performance impact with OTA

[angelolloqui]

Hi, I am debugging some slowness in a collection view we have with several strings on it, refreshed very frequently.

For my surprise, more than 80% of the time is spent into the PhraseSDK. Attached screenshot focused on the NSLocalizedString subtree.

As you can see, I do not have the code to check the exact method invocations, but it seems that the code is doing some stuff with NSFileManager as well as with Url consuming 30% of total time, and some calls to Locale.availableIdentifiers with other 14% and 12%, so making up more than half the total time.

I understand there is need for some work to be done inside the SDK, but is it possible you cache some of this info internally so you do not have to make it every single time? the most interesting aspect of this particular example is that the key passed into the NSLocalizedString is most of the times identical, so if you would use a cache we could just hit the cache most of the times, resulting in much faster performance.

Can anyone take a look to possible optimizations? when repeated multiple times it makes a huge difference to use or not your SDK.

[winkelsdorf]

Hi @angelolloqui,

thank you for reporting this! With the given information it's a little bit difficult to say where the performance bottleneck really is. The UICollectionView is known for its bad performance under some circumstances.

You're right about that we are fetching things on-demand from the bundle, to ensure the data is still valid. Optimizing the Bundle URL lookup is a very good suggestions, we'll look into this for the next release. An internal cache layer is something we would like to try to avoid, as it has other drawbacks here depending on the use-case (invalidate, memory overhead etc).

That said, I would say that a lookup of a Bundle URL and the other related calls (i.e. forwarding localizedStringFromBundle and checking the Locale) should be nowhere near to 600 ms. Those calls are going to (Swift) Foundation and should be blazing fast anyway.

I am curios: What are your profiling settings? Is Profiling in your Scheme running in Release Mode as Apple suggests? Are compiler optimizations enabled when you're building for profiling (-O setting)? If you're by accident profiling a Debug Build, even simple string operations might be 100 times slower.

hth!

Frederik

[angelolloqui]

Hi @winkelsdorf , thanks for answering.

Regarding your questions, yes, I was profiling under debug because my intention was only to find out the cause rather than having an exact number of ms of work spent, so for sure, in pro it will not take 600ms (but enough to perceive framedrops).

Behind that, I saw another optimization in my own code, because we were doing translation twice for same string, so reusing that saves us quite some time, together with more aggressive pagination solved the issue (we were having a huge list of items, where we translated them all instead of doing in smaller chunks with user scrolling). So we are not in a hurry anymore, but it is still interesting if you can improve performance since having to work around these things feels wrong... ideally, Phrase should perform almost equally to the original translation methods.

Thanks!

[winkelsdorf]

Hi @angelolloqui,

thank you for your valuable feedback! Glad you were able to reduce the issue for your project. Yes, absolutely, we will check and identify potential issues, especially regarding caching the Bundle (at least the Bundle URL Instance).

Best Frederik