Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Murray Roke 503 posts 966 karma points c-trib
    Jun 14, 2010 @ 05:46
    Murray Roke
    0

    Performant way to get all a Document's Descendants

    I've created this method to get all descendants of a given document.

    But it's VERY slow, 10 seconds! is there a faster way to do this?

    It doesn't have to be fast because it's for an admin report.

    However it's very slow and it's got less than 100 records in that branch of the tree.

            public static IEnumerable<Document> AllDescendants(this Document node)
            {
                foreach (Document child in node.Children)
                {
                    yield return child;
                    foreach (Document grandChild in child.AllDescendants())
                        yield return grandChild;
                }
            }

     

  • Niels Hartvig 1951 posts 2391 karma points c-trib
    Jun 14, 2010 @ 06:21
    Niels Hartvig
    3

    The Document API is insanely slow in v4.0.x. It has been dramatically improved in 4.1.

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Jun 14, 2010 @ 07:28
    Aaron Powell
    0

    The only way to speed it up is to build your own caching, put it into a singleton so it's maintained for live of the app pool.

    It'll give you good performance if you're running it multiple times.

  • Murray Roke 503 posts 966 karma points c-trib
    Jun 21, 2010 @ 03:56
    Murray Roke
    0

    It's probably only going to run once a month. :-)

  • Murray Roke 503 posts 966 karma points c-trib
    Jun 21, 2010 @ 04:04
    Murray Roke
    0

    P.S. I'm concerned with speed now, because before too long it will have a lot more data to deal with.

    I think when that occurs the best solution will be to upgrade to 4.1

    Also.. in the most data heavy case of what it exports I could actually get away with using the nodeFactory, but that will require duplicating the code for nodes as opposed to documents, or as @slace suggests: implementing a factory to generate adaper/proxy classes instead

  • Murray Roke 503 posts 966 karma points c-trib
    Jun 21, 2010 @ 04:08
    Murray Roke
    0

    P.S. I'm concerned with speed now, because before too long it will have a lot more data to deal with.

    I think when that occurs the best solution will be to upgrade to 4.1

    Also.. in the most data heavy case of what it exports I could actually get away with using the nodeFactory, but that will require duplicating the code for nodes as opposed to documents, or as @slace suggests: implementing a factory to generate adaper/proxy classes instead

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Jun 21, 2010 @ 13:19
    Aaron Powell
    0

    Depending on what data you actually require it might be possible to just query the database for path which contains your start id

Please Sign in or register to post replies

Write your reply to:

Draft