Fwd: CoreData model optimization? (slow on insert with fetches)

  • I can see two different part where the app/this model is slow:
    - fetching the list of thread root (= first message of a thread
    without any parent)
    - inserting lots of messages into managed context

    about the first part, Core data seems to be slow with a simpe model
    with a simple Message entity that have parent/child relationship (so
    where there aren't any classification in ChildNode/RootNode).
    The other part regards inserting lot of message and it's linked to the
    fact that I've a relationship for subject and author. Core Data is
    slow when I try to associate a subject to to the message (in fact CD
    need to search for an existing subject entity with that text and
    return it/create a new entity if the search is falied); it's very slow
    because at each insert it needs to fetch for other two entities
    So I'm searching a way to optimize it.
    Probability the first thing to do is to incapsulate as attributes both
    author and subject (and I'll eliminate the problem with insert time).
    Then I need to speed up fetch for root parents; is childnode/rootnode
    separation a good way to do it (in fact I'll have less objects to
    fetch if I'll search for only root nodes instead of all
    messages-without-parent, or not?).

    2007/10/2, I. Savant <idiotsavant2005...>:
    >> Why?
    > Missing information: What specifically is slow? What are you
    > fetching that is slow? How ***EXACTLY*** are you fetching it? Are you
    > sure you're not doing something to cause it to be fetched multiple
    > times? These details directly affect performance and you've left them
    > all out for some reason.
    > Suggestions: Read back over the Core Data Programming Guide and the
    > Key-Value Coding Programming Guide. The former so you can better
    > understand how things work and the latter so you can name things a
    > little better (your attribute names are bizarre).
    > Regarding overall design of your model, Mail deals with "Message".
    > A message may belong to a thread (and may be sorted by thread) but a
    > message is still a message. I would think separating out "Subject" as
    > a separate entity would only cost you more work, not less.
    > How about you describe the *basic*, plain-English model you're
    > dealing with (rather than the "optimized" version you posted)? It'd
    > make it easier to make suggestions.
    > --
    > I.S.
previous month october 2007 next month
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today