Memory crash

[cflorion]

I integrated Ensembles+Multipeer in my app. But when using it on devices it crashes after a while because it exceeds memory. I want to work on that memory issue. Would you have any idea where this come from ? That would help a lot if you had any directions to give me so I don't spend time finding things you already know :)

Thanks!

[drewmccormack]

Is it definitely in the new multipeer stuff?

The public Ensembles isn't very economical with memory. It does sometimes pull the full DB into memory. Fine for smaller apps, but not great for larger data sets.

Good news is that Ensembles 2 is lightyears better, and is very close to release...

I can't think of anything offhand that would cause large memory in the multipeer stuff. Is it maybe a lot of overlapping operations?

[cflorion]

I'll run some tests. But I'm not sure that it comes from Multipeer stuff per se. I'd say that it's due to the fact that with multipeer, syncs happen really often (every few seconds in my app) and that my data model is more complex than idomatic (55 tables).

I'll dig into it. I can't wait to try Ensembles 2 though ! :)

[drewmccormack]

55 tables. Wow!

Why are the syncs happening so often? Can you wind that back?

Drew

On 07 Jul 2014, at 22:59, cflorion notifications@github.com wrote:

I'll run some tests. But I'm not sure that it comes from Multipeer stuff per se. I'd say that it's due to the fact that with multipeer, syncs happen really often (every few seconds in my app) and that my data model is more complex than idomatic (55 tables).

I'll dig into it. I can't wait to try Ensembles 2 though ! :)

— Reply to this email directly or view it on GitHub.

[cflorion]

I actually made the choice to make syncs happen that often.

I'm working on a POS app. When I add a product on an order I want it to be sent to the other devices instantly. For now I have two managedObjectContexts:

• one mainContext for the UI that does not have a persistentStore. It saves really often (without sending to the other peers via Ensembles since the context doe not have a persistentStore)
• one rootContext that is the parentContext of mainContext and that has a persistentStore. I have a timer (2sec) that makes both context save (if there are changes), that's where changes are sent to the other devices.

Do you think syncing that often (closest to real time possible) is too much for Ensembles ?

[drewmccormack]

Hmm, I never really considered that case.

I think you can sync often, but 2 seconds may be a bit too short. You probably should look at how long a typical merge is taking, and base the time interval on that.

Note that merges get queued, so doing it too often could cause a backup. Better to wait for the completion, and schedule 2 secs after that.

With multipeer, you have a second type of sync: the files themselves. You will probably need to experiment to find a good combination of time intervals for syncing files and merging.

Drew

On 07 Jul 2014, at 23:13, cflorion notifications@github.com wrote:

I actually made the choice to make syncs happen that often.

I'm working on a POS app. When I add a product on an order I want it to be sent to the other devices instantly. For now I have two managedObjectContexts:

one mainContext for the UI that does not have a persistentStore. It saves really often (without sending to the other peers via Ensembles since the context doe not have a persistentStore) one rootContext that is the parentContext of mainContext and that has a persistentStore. I have a timer (2sec) that makes both context save (if there are changes), that's where changes are sent to the other devices. Do you think syncing that often (closest to real time possible) is too much for Ensembles ?

— Reply to this email directly or view it on GitHub.

[cflorion]

Note that merges get queued, so doing it too often could cause a backup. Better to wait for the completion, and schedule 2 secs after that.

Really interesting, thanks!