Saving ParseObjects with save() sometimes take several minutes.

[krausegil]

The problem:
Sometimes saving parse objects using the save() function takes several minutes.
In those 2-15 minutes the save function will not return.

Background:
In our app, for each Class that we want to save to the servers, we create a class extending ParseObject, using an inheritance tree. For example:
Both class ParseDog and class ParseCat extends ParsePet, which in turn extends ParseObjectWrapper. Some classes like ParseNotification extends ParseObjectWrapper directly.
For users we use the built in ParseUser class.

We do all our work with parse in a closed parse module.

We have Objects which reference other objects (always from another class), we use reference arrays, and so on.
We do all relations as recommended in the parse documentation.

Other issues that might be worth mentioning:

• We had a big issue with ConcurrentModificationException. Eventually we had to use a read-write lock for all objects, so if we write 1 object, we don't read any object even if it is from a completely unrelated class.
• When running in debug mode, parse usually works very slow.
• The app is still in beta. So a load issue is unlikely. Yet, sometimes we get above the 30 calls / second limit at midnight, and then it drops back to almost zero.
• We use saveAll() a lot, but till 2 month ago we didn't, and we had the same problem back then too.

More about the problem:

• Usually, once it happens, it will happen from all devices for several hours and up to a day.
• Sometimes it will happen only for few devices / users. In those cases usually some objects will get saved normally while others won't, and the issue will remain for days.
• Using saveInBackground doesn't help. We tried and the callback function have never be called or it took several minutes.
• We don't have any issues with reading from the server.
• We tried to flatten the inheritance tree (remove the classes ParseObjectWrapper & ParsePet). This did not help.

Links to other bugs that we thought might be relevant:

• http://stackoverflow.com/questions/27051940/parse-uploading-data-sometimes-needs-forever-and-does-never-finish
• http://androidstackoverflow.blogspot.co.il/2014/07/android-sometimes-saveinbackground.html (less related as we use save and don't do 2 saves in the same time)
• As we use subclasses of subclass, this might be related:
  http://stackoverflow.com/questions/31682495/subclassing-a-parseobject-subclass-android/31682925#31682925 (but in our case we don't register classes that are inherited + we tried removing the inheritance and it didn't help)

[wangmengyan95]

Hi @krausegil,

1. Subclass ParseObject should not cause a performance problem. We use the same API endpoint to save a ParseObject and the subclass of a ParseObject.
2. I assume the debug mode you mean is the debug build type. We do not have any configuration for build types. It is wried the performance is different in different build types.
3. When we save a ParseObject, we save all its children first. So if your save a ParseObject which has lots of children, it may take more time. But several minutes is too long, normally a save call will take less than one sceond in good network condition. So for now, it sounds like a backend issue to me. We continue to use the FB bug tool to track backend issues, where you can confidentially submit information about the exact app that you are having issues on. Could you file an issue there?https://www.parse.com/help
4. For the ConcurrentModificationException, could you paste some code snippet which cause this bug?

[parse-github-bot]

Thank you for your feedback. We prioritize issues that have clear and concise repro steps. Please see our Bug Reporting Guidelines about what information should be added to this issue.

Please try the latest SDK. Our release notes have details about what issues were fixed in each release.

In addition, you might find the following resources helpful:

• Documentation: https://www.parse.com/docs
• Google Groups: https://groups.google.com/forum/#!forum/parse-developers
• Stack Overflow: http://stackoverflow.com/tags/parse.com

[parse-github-bot]

This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.

[parse-github-bot]

We are closing this issue due to another 7 days of inactivity. If you have additional information to help pinpoint this issue as an SDK bug, please reopen it with the additional information.Thank you for your feedback.

[krausegil]

Hey, sorry for the delay.
We found a workaround and once it worked we had many other bugs to solve to stabalize the product.

Anyway, the workaround was removing the inheretance so all of our Parse class inherite ParseObject directly.
That means ugly not OOP code - duplication of the code of "ParsePet" both in ParseDog and in ParseCat, for example. But it seems to have solved the problem. Unlike previous attempts to solve this time when we went back to old versions the problem returned.

Anyway, we looked for it in your documentation and found no where that it says something about this bug / limitation. We only got the idea to try it from here:
http://stackoverflow.com/questions/31682495/subclassing-a-parseobject-subclass-android/31682925#31682925

Please do mention it in big latters in your documentation. That issue cost us lots of development time especially as it sometimes work and sometimes doesn't...

As for #2 (Debug mode) - I'm talking about when we run the app with the Android Studio debugger (on a real device / Genymotion). When we do this, any parse call takes segnificantly more time.

#3 : Now that we fixed the inheretence issue, most calls take (with a 60MB internet connection in TLV) 2-8 seconds. and they don't have many children objects. Specifically not many that have changed.

[grantland]

@krausegil Could you clarify whether or not using nested ParseObject subclasses worked (albeit slowly)? I'm a little confused as your original comment made it seem like it worked (slowly), but the stackoverflow thread you linked to in your second comment stated that it didn't work.

RE debug mode: debug mode will always be slower as the Android debugger is attached to your application, monitoring everything such as the call stack of all the threads in your application. If all you're testing is speed, you'll need to make sure that you consistently use the debugger or not across all your benchmarks. I recommend not using it since all you're worrying about is speed.

RE children: could you instrument your network calls with ParseInterceptors to verify how many children are getting saved/network requests being made?

I also believe that we'll need a minimal sample project that reproduces your issue to deduce what's happening and to provide a fix.

[krausegil]

1. ParseObject subclasses:
   1.1. For 97% of the time - it worked but ~3 times slower (I'm guessing) than it worked after flattenning the inheretence tree, for some objects, and at least 50% slower for all. Here I compare time for APKs running on real devices but not neccesserly uploaded to google play.
   1.2. About once a month (not consistent, no pattern) - things stopped working. As in most write calls to the server got replies. Not even an error returned. The save() method calls just never returned...
   1.3. The stackoverflow link isn't our case. It was our inspiration to think about flattenning the inheretence.
2. Debug mode:
   We know that the debugger is slow. Aspecially on Genymotion.
   But we it seems that the code that contains parse calls and working with parse objects is much slowwer then the UI / mixpanel / threads / location code in debug mode.
   We are doing "fair benchmark".
3. Children:
   I'll look at it another day. It is now 1:30 AM here so time to stop working.
4. Sending you code:
   I assume it should be posible, but in private channels (we are not open source).
   Let me know how can we do it and I'll check it with my co founders.

[parse-github-bot]

This issue has not been updated for 7 days. If you have additional information to help pinpoint this issue as an SDK bug, please comment on this issue. We will close this issue in 7 days if no additional information is provided. Thank you for your feedback.

[krausegil]

@grantland @wangmengyan95
Please your reply.
In the last few days some of our write calls are super slow again. some take about 1 minute for saving an object edit. Objects of thios class only have 2 children. Non of them is "derty" when this save operation is done.

If this problem was in an operation done by all users and not only in an "adminstrator" platform - this would have killed the app.

[grantland]

1/ Subclassing shouldn't cause significant slowdowns, especially for asynchronous code.

3/ We still need this information.

4/ As per our Contributing Guidelines, we need a concise repro to make this actionable such as a small project that shows the problem you have described.