-
-
Notifications
You must be signed in to change notification settings - Fork 878
Batch pointer fetch by 25 objects on querying from LDS. #605
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
Conversation
cc @FreudGit checkout out this branch and test it, let me know how it goes. |
86c31d2
to
0899727
Compare
Sure, tomorrow first thing! |
Something like: pod 'Parse', :git => '[email protected]:ParsePlatform/Parse-SDK-iOS-OSX.git', :branch => 'nlutsenko.lds.query.batch' |
@nlutsenko From my iPhone 6s. Look like we have a 15% performance improve. (i'll have a iPhone 5 soon to test\get more interesting result) one thing strange(not only releted to this specific branch)= Look at the code here: When i call getFullContent_toLocalDataStore, ALL next call to get result are near 0.1 sec. If I open the app and ask for result direct(queryShareFromParse_UsingLocalDataStore), result are near .45. Look like pinAllInBackground keep all in memory :) https://docs.google.com/spreadsheets/d/1QSRgTNXMdS4gNC62yA_zfNp4IhdY1SyUYD3xwb_vM1Q/edit?usp=sharing |
@nlutsenko iPhone 5 = 2.2s(this branch) versus 2.5s.(1.10.0) |
W00t 15% perf improvement. |
PFConstraintMatcherBlock matcherBlock = [self.offlineQueryLogic createMatcherForQueryState:queryState user:user]; | ||
|
||
BFTask *checkAllTask = [BFTask taskWithResult:nil]; | ||
NSArray *uuidBatches = [PFInternalUtils arrayBySplittingArray:task.result withMaximumComponentsPerSegment:25]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not 100% sure why we're splitting this here instead of doing it in one big batch. Care to clue me in?
We still only have one query that can go through in the DB at a time, why have extra context switches for smaller batch sizes?
Just seems like needless work, especially when continueWIthSuccessBlock:
will always run on the same thread anyway...
The only rationalization I can think of is maybe if we wanted to add progress reporting it could be useful, eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We split to make sure we do not allocate a lot of memory. Will change the limit to 64 to keep it at power of 2.
0899727
to
f7054de
Compare
@nlutsenko updated the pull request. |
f7054de
to
370060b
Compare
@nlutsenko updated the pull request. |
Batch pointer fetch by 25 objects on querying from LDS.
Contributes to #32 by improving performance about ~20% compared to previous one on basic queries.
(using a benchmark with 1000 objects in LDS)
Batch pointer fetch by 25 objects at once, instead of running 25 separate queries.
We can do more in this space by parallelizing the fetch further, but this is the first step into this direction.
Depends on #603