Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load performance pains #27

Closed
RSully opened this issue Jul 15, 2013 · 5 comments
Closed

Load performance pains #27

RSully opened this issue Jul 15, 2013 · 5 comments

Comments

@RSully
Copy link
Owner

RSully commented Jul 15, 2013

See issue #8 starting at this comment: #8 (comment)

-genBitmap is slow and causes the color picker to block the main thread during each initialization.


Prior discussion:

@simonbs:

I'm sorry for jumping into the discussion like this but I'm very interested in hearing if anyone have figured out a way to improve the performance when loading the color picker? It gives me a very bad performance on my iPhone 5 so when pushing a view which contains the control onto my navigation stack, it does so without any animation. However, it seems that when the control has been loaded, the performance is really great.

@stuartjmoore:

I'm guessing the load slowdown is due to the loops and calculations in genBitmap. There's no need to generate a gradient background every single time (since the color wheel will likely never resize), so I'm to experiment with a static background from a screenshot.

@RSully
Copy link
Owner Author

RSully commented Jul 15, 2013

My comment from prior discussion


I've created a branch for testing push/pop of the color picker within a UINavigationController

git fetch
git checkout enhance-nav_controller

Branch: https://github.com/RSully/RSColorPicker/tree/enhance-nav_controller
Comparison: master...enhance-nav_controller

This has been merged into #26

This has been merged into master


@stuartjmoore I agree the issue is likely generating the initial bitmap. I am still interested in keeping it resizable (though I'm not sure how often that would actually be used - right now probably never considering how slow it would be).

Time profiler:

screen shot 2013-07-14 at 12 21 02 pm

Each of those purple spikes is pushing another view controller.


A few ideas are going through my head:

  • Generate the bitmap off of the main thread (GCD comes to mind)
  • Cache the bitmap on each init based on the size

Combining these ideas yields an interesting approach. Perhaps you would call something like this when the app launches:

[RSColorPickerView prepareForSize:CGSizeMake(256.0, 256.0)];

This could generate that bitmap in the background and then whenever initialized with that size loading would be near-instant.

The downside of course is that these bitmaps would sit in RAM even if the user never needs a color picker.


Edit:

Another time profiler without "Show Obj-C Only":

screen shot 2013-07-14 at 12 36 34 pm

This was referenced Jul 15, 2013
@RSully
Copy link
Owner Author

RSully commented Jul 19, 2013

I've created #28 after someone mentioned the Accelerate.framework to me. This might be the first step in solving these performance issues. If anyone has any experience or input on which direction to head in, let me know.

@RSully
Copy link
Owner Author

RSully commented Jul 21, 2013

Wow, well it has been a long week. Besides getting my feet wet with CocoaPods and merging in some contributions, #28 is a huge overhaul.

A brief rundown (work in progress of release notes):

  • Most trig code has been converted to Accelerate.framework
  • HSV to RGB conversion is done manually (UIColor was too slow)
  • Bitmaps are cached when generated
  • Added -prepareForDiameter class method to preemptively create a cached bitmap (computed in background)
  • Addressed bug that would inadvertently disable animations

Some possible issues:

Even more importantly, out of all of the changes made, which ones might not be great ideas? There are a lot of changes in that branch.

@RSully
Copy link
Owner Author

RSully commented Jul 23, 2013

Regarding

What happens if a color picker is created while -prepareForDiameter is calculating?

I have changed the implementation to use NSCache (thread-safe) and NSOperations. It should be handled correctly now.

Should bitmaps always cache by default?

I'm still on the fence about this. I'm using NSCache now so even if they did cache by default it shouldn't be a huge burden. However, I have not been able to get it to evict an object (in the simulator) so I still want to do some more on-device testing.

@RSully
Copy link
Owner Author

RSully commented Aug 24, 2013

I think it is safe to close this now. I just released v0.8.0 that includes many performance updates. If anyone has any issues please feel free to create a new issue and we can continue this discussion.

@RSully RSully closed this as completed Aug 24, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant