That's all very interesting information, Dave, and worth exploring, but it doesn't explain why the standalone call to file_storage__new_file takes such a long time.
It does a create_item first off ... first guess is the tree sortkey stuff as has been discussed above. When Jeff has time to munge 5.1 perhaps he can introduce his changes to file storage first, and we can see if this fixes the problem?
Of course the 5.0 basic object creation tree sortkey speed-up would also need to be applied to Collaboraid's system, just speeding up the creation of one of the two tree sortkeys involved won't solve the problem.
The other troublesome call in file_storage__new_file is the call to update the last modified attribute of the object and all its context_id parents. For one thing this doesn't seem right, OF sort of snuck it in while working on .LRN. The last modified attribute in the original aD object model was intended to track the last direct modification of an object, not those who inherit permissions from the object. For a second thing, the recursive nature of the implementation might be slow ...
But I think the first place to look is the sortkey stuff. When Jeff gets the mods made to the CR (which should help the performance of several packages) we can do some performance testing to see if the update last modified procedure is also a problem.
