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

WWDC Performance #23

Closed
wants to merge 12 commits into from
Closed

WWDC Performance #23

wants to merge 12 commits into from

Conversation

cnstoll
Copy link
Contributor

@cnstoll cnstoll commented Jun 15, 2013

So I had an itch to do some performance optimization at WWDC after watching the Core Data Performance session and here's the result. On my sample test App.net dataset I'm seeing performance improvements from the following sample sizes.

1000 records: 300ms
10000 records: 3s
100000 records: 30s

Those are fairly complex records which have multiple relationships and populate multiple attributes per relationship entity. It's a significant performance improvement just with a few basic algorithmic changes.

Part of that pulls in Luke's (cc @urbanappetite) changes from the other pull request. Part of it is changes I made at WWDC.

Please review the changes made to the core MMRecord classes. The rest of the changes are the addition of a new Example app which allows you to control things like test data sample size via a method in the app delegate. That makes it easy to try different sizes and diagnose issues quicker.

Thanks,

  • Conrad

@ghost ghost assigned cnstoll Jun 15, 2013
@blakewatters
Copy link

Man I saw this pop up in my email since I am watching your repository and would love to offer you a coherent code review but the signal to noise ratio in this pull request is off the charts. You have a vendored AFNetworking update and a bunch of ancillary stuff in the changeset that makes it really hard to evaluate the content of the performance focused changes.

Maybe I can help with some focusing questions:

  1. What is the slowest parts of the MMRecord sync process?
  2. How are you measuring the speed of those parts?
  3. How are you evaluating the progress/regression of these parts?
  4. If I sent you a pull request tomorrow with an awesome new feature that also happened to slow the library down by an order of magnitude would you know? How?
  5. Can you isolate/quantify your performance independent of network/host machine conditions?

I love that you are working on this and taking a look at the performance problems inherent in dealing with Core Data. There may be an opportunity to share some code between RestKit and MMRecord once you get your arms around your performance profile.

Hope this is helpful -- I'd love to give your more substantive feedback on a more granular level in the future.

@cnstoll
Copy link
Contributor Author

cnstoll commented Jun 15, 2013

Hey Blake,

That's super helpful feedback. Let me break out the changes to the Example project and re-submit this. The actual changes to MMRecord are fairly small, so breaking out all the Example stuff should help focus this in. I'll post back when that's done.

Thanks,

  • Conrad

@cnstoll cnstoll closed this Jun 15, 2013
@cnstoll
Copy link
Contributor Author

cnstoll commented Jun 15, 2013

Hi Blake,

If you get a chance, please check out the new pull request here:

#24

Thanks,

  • Conrad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants