Mobx-state-tree: Question about performance

Created on 2 Aug 2017 · 8Comments · Source: mobxjs/mobx-state-tree

Has anyone seen any issues around performance?

So i have a Document with these attributes:

    id: types.identifier(),
    name: types.string,
    description: types.maybe(types.string),
    documentId: types.string,
    size: types.number,
    filename: types.string,
    url: types.string,
    fileExtension: types.string,
    documentType: types.maybe(types.string),
    categories: types.maybe(types.array(types.reference(DocumentCategory))),
    products: types.maybe(types.array(types.reference(Product))),
    imageUrl: types.maybe(types.string),
    path: types.maybe(types.string),
    isDownloading: types.optional(types.boolean, false),
    downloadedBytes: types.optional(types.number, 0),
    makeAvailableOffline: types.optional(types.boolean, false),

When I load data from a web server, it takes nearly 15 seconds to load 340 of these objects these into memory.

React Native 0.45, tested on iOS 10.2 sim, 10.3 device, android 6 (api 23) device -- all perform the same
this is also with categories & products being null in the source data

Crazy right?

But...

Then save the snapshot to storage.

When I reload the app, i load the containing model from this serialized version, and it loads instantly.

Anyone experience something like this? It seems the more properties a model has, the slower things go?

I can come up with a repro, just wondering if anyone is seeing something like this.

I hope it's just me using it wrong. Ha!

Source

skellock

Most helpful comment

So....... uh....... 👀

The performance issues I was seeing wasn't related to MST.

It was my interaction with FlatList in React Native. Switching from variable height cells to fixed height cells made everything super quick again.

Whatever was pinning the CPU was preventing my highly scientific console.log('here') statements from being written out. So the 16 second slow down was 100ms of MST work, and 15,900ms of having my cries for help being heard by the terminal.

giphy

skellock on 10 Aug 2017

❤1 🎉1

All 8 comments

He are already working on that :) Will be improved in next versions :)

mattiamanzati on 2 Aug 2017

Sweet. Was it one thing? or a collection of small things? I'm curious. I went looking and didn't find anything that stood out as OMGBAD!

skellock on 2 Aug 2017

Double check, is all loading done in a single mobx or mst action?

Op wo 2 aug. 2017 22:22 schreef Steve Kellock notifications@github.com:

Sweet. Was it one thing? or a collection of small things? I'm curious. I
went looking and didn't find anything that stood out as OMGBAD!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-state-tree/issues/284#issuecomment-319787009,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABvGhHz87M1hTzqzBIE05odheJUXfqAvks5sUNp1gaJpZM4Orgli
.

mweststrate on 2 Aug 2017

MST action.

    /** downloads the latest documents */
    *getDocuments() {
      this.isFetching = true
      const documents = yield (this.api as Api).getDocuments()
      this.documents = documents // TODO(steve): halp!
      this.isFetching = false
    },

The document asssignment is where the problem is. If we cut it to a list of 30 instead 340, it’s fine.

These aren’t large objects either. description Being the largest field at a couple of paragraphs.

It’s after the response from the api as well.

The only active observer is a FlatList in react native. I’ve unhooked all onSnapshot, onPatch and onAction to try minimize side effects.

Again (not sure if this is a clue or not), recreating these objects from a snapshot in a GlobalState.create(dataFromStorage) is instant. FlatList populates in milliseconds.

skellock on 3 Aug 2017

@skellock would you mind creating a test for this in the test suite as a PR? That can serve as starting point for #254 :)

mweststrate on 3 Aug 2017

Will do.