Is the number of items in "generated list of possible options" -- that is, the SQL IN LIST small? Is "path" an indexed column? Doing select statements with IN lists is often quite inefficient.
For n pieces of URL parts, it's 2^n - 1. We cut at six, so it's maximum is 63. Here it is for three pieces: node/12/edit node/12/% node/%/edit node/%/% node/12 node/% node this is seven. Whether path is an indexed column or not is not a question at this point. It's more like an assert: path must be indexed.
Is the expected result set a single item, a few items or a lot of items? (The answer is probably evident from an understanding of just exactly how this menu scheme works, but I admit I have not quite grasped it completely yet.)
One item. Everything is packed into that item by the builder. At some point I thought you will have three items, then approximately n items or less (depending on how many children you have). But then came the BarCamp menu talk and now everything is in the builder.
Unserializing a massive tree is certainly slow. Let's be sure we don't shoot ourselves in the foot with an algorithm which may be subject to SQL end-cases that take forever to retrieve. :-)
Let's hope not. We are trying to make it as fast as possible. Currently, I work on the builder, to build an array out of depths and weights, use array_multisort and then vancode the stuff so that the navigation block is in correct order. Regards NK