Performance regression on Lottie 3

[manolosavi]

Check these before submitting:

• The issue doesn't involve an Unsupported Feature
• This issue isn't related to another open issue

This issue is a:

• Non-Crashing Bug (Visual or otherwise)
• Crashing Bug
• Feature Request
• Regression (Something that once worked, but doesn't work anymore)

Which Version of Lottie are you using?

Lottie 3.0.4

What Platform are you on?

• MacOS
• iOS

What Language are you in?

• Swift
• Objective-C

Expected Behavior

Same or improved performance as previous versions of Lottie when running animations

Actual Behavior

Running an animation on a loop using Lottie 2.5.3 consumes around 16% CPU, while running that same animation on Lottie 3.0.4 consumes around 43%

Code Example

Animation JSON

Attached file

[buba447]

Duplicate of #832 and #828

[manolosavi]

@buba447 for what its worth we also tried installing off of master today and we didn't see any difference in CPU usage

[buba447]

I imagine there wouldnt be any difference. I havent had a chance to deep dive into the performance issues yet. The issues will be updated when I do though!

[alexbredy]

Same issue here. I am updating the currentProgress property of a Lottie animation on scrollViewDidScroll (creating a parallax offset) and performance dropped a lot since we migrated from v2 to v3. CPU consumption jumps making the frame rate drop.

[manolosavi]

@buba447 hi! just wanted to let you know that I just tried out version 3.1.2 and there are still issues in this version. The same screen shows CPU utilization of ~45% on 3.1.2 vs ~18% on 2.5.3, and the reported "energy impact" is "very high" vs "high".

[buba447]

Yeah I still haven't had a chance to work on the performance issues. They are caused by some limitations in the swift language cause by automatic memory management in structs. To fix the issue requires a pretty hefty refactor that I haven't had the resources to tackle. (Im working on lottie in my personal free time) We had to bump to 3.1 because of an API change. I will keep this thread updated when I get a chance to work on the performance issues.

…

On Aug 21, 2019, at 5:31 PM, manolo ***@***.***> wrote: @buba447 hi! just wanted to let you know that I just tried out version 3.1.2 and there are still issues in this version. The same screen shows CPU utilization of ~45% on 3.1.2 vs ~18% on 2.5.3, and the reported "energy impact" is "very high" vs "high". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[manolosavi]

@buba447 thank you!

[Rapsssito]

Any news on this issue? I am experiencing 1 FPS frame drops with any animation on iOS, while they perform solid 60 FPS on Android (using lottie-react-native).

[paolo96]

I'm experiencing this issue too, any news? @buba447

[kirillsh]

+1
version 3.x is disappointing from performance point of view, have to downgrade to 2.5

[antonioallen]

Yeah, extremely poor performance CPU at 90% and memory when from 65mb to 1.2GB. Going to try downgrading as @kirillsh suggested.

[fila]

Having an issue with Memory usage while utilising the latest Lottie version (3.1.3). Tried to downgrade to 2.5.3, but this didn't actually help:

• the memory usage is the same (even went up a bit from 503.4 MB to 506.6 MB)
• the CPU usage did drop, but insignificantly: from avg. 7% to avg. 3%

[flypigo00o]

I have same problem.
I used for 2.5 downgrade.
But I worry that Apple's fast update cycle will make 3.0 updates inevitable.
I will continue to care about this problem. Any news on this issue?

[buba447]

Hey Everyone!

Some updates here. Ive tracked down some of the performance issues. The main issue comes from the way swift handles automatic memory management for structs and generics. Apparently there is a lot of overhead for swift memory management. This is increasing the memory footprint as well as causing a massive performance hit. The good news is that this is a fixable problem. The bad news is that it requires a refactor to remove generics and to rethink the usage of structs in many situations. This would be a fairly massive project.

For those that don't know, Im the sole developer and maintainer of Lottie-ios. I did the swift rewrite last year (also I wrote the objc version before that) and am continuing to maintain this project in my free time. I am not employed by Airbnb so add an emphasis to the word free in free time. As you can imagine finding time to work on such a large project when I have paying contractor jobs waiting around is difficult. I'm hoping to raise some funds to tackle this refactor using github-sponsors. If you or anyone you know would be interested in sponsoring this project, please share this repo! theres a sponsor button right at the top ^

Thanks for using Lottie and for keeping me posted on everything going on. I have created a project for this issue and will be tracking progress there. The progress is attached to this issue.

[Rapsssito]

@buba447, greatly appreciate your work. I would sponsor the project if I could. Please, consider pinning an issue with some TODOs so we, the community, can help you with this refactoring!

[yuweipei]

any updates on the sponsorship or the TODO list that the community can help out?

[dreampiggy]

Any update about this issue ?

In some test lottie images, the performance drop down is 60% compared to Lottie 2.x. See: SDWebImage/SDWebImageLottiePlugin#1

Our wrapper framework now have to use Lottie 2.x instead of 3.x because of this poor performance.

[ppamorim]

I am experiencing the same. Please help :)

[dreampiggy]

I've tried another solution, I integrate Samsung's rlottie implementation on iOS/macOS/tvOS/watchOS.

The rlottie's performance is good on production, however, it support bitmap rendering only. Each time you change the canvas size, you need to re-render. This means you need to use UIView's drawRect method if you want dynamic size changing.

If you're using SDWebImage already, have a try SDWebImageLottieCoder, which play the best performance on massive UICollectionView layout. Suitable for small stickers (which don't need vector size changing)

If you don't use SDWebImage, don't worry, you can still integrate the rlottie using our wrapper rlottie-Xcode, which provide both CocoaPods/Carthage/Swift Package Manager support, make it easy for life without C++ cross-compiling issue... 😪

[Yamyee]

Is there a better way than downgrading？

[david6p2]

Hi @buba447 do you have a TODO list of the tasks that needs to be done, so some of us can help you out.

[rkeshavappa]

@buba447 Any solution on how to fix the performance hit ? We are using a Lottie file which is spiking up the memory to 40MB and there a good amount of lag on load.

[ddcrobert]

Not really a solution but might help in some cases...
The AE compositions provided by my designer were huge, like 2000x2000. Even if that's vectors... the lottie view has to be downscaled to match the constraints. The more it had to downscale, the more the performance were poor.
Reduced the composition (File/Script/Demo Palette) from 2000x2000 to 100x100.

[Tr736]

@ddcroberts solution didn't work for me either. Ive had to roll back to 2.5.3 which works but doesn't support as much AE effects. Shame, hope this is resolved soon

[andemengo]

@buba447 any updates? Could we help you to fix this issue?

[MazZilaaaa]

Any updates?

[paolo96]

#1328 this seems to solve the issue, @buba447 can you give us an update regarding this? thanks

[calda]

Today we released Lottie 3.4.0 which includes a new rendering engine powered by Core Animation (more details here). This new rendering engine has significantly better performance, and should resolve the performance issues folks have been encountering with the previous main thread rendering engine. Please try it out by setting the LottieConfiguration.renderingEngine feature flag, and feel free to report any new issues that you experience when using the new rendering engine.