View Single Post
  #21  
Old 08-05-2022, 04:13 AM
Spliff Spliff is offline
Registered User
 
Join Date: 04-07-2021
Posts: 192
Sorry to hear that, all the more so since I made the observation that after lots of moving items around,

"Compact and Repair" seems absolutely necessary!

Here is my observation:

I had not "compacted and repaired" anymore, in order to avoid the above, it's my main db with less than 15,000 items, and sized about 0.6 gb.

Then, in order to get some "intermediate order" at least into my "Inbox" in that - it had grown way faster than I had been able to "file" the items in it, thus had grown to near 2,000 items - I did a "preliminary filing" for its contents, by filing it all, in the meanwhile, not into dozens of real filing targets, but into 5, 6 intermediary ones (parent items = filing targets in the inbox, too, instead of outside of it, as the real targets are, so from a very long item list in the inbox, I went to a short list, with just some items "holding" (and thus "hiding from view") long lists of child items).

This was some days ago, and no problem after. Today then, from one day to the other, new item creation took, instead of less of a second, about 15 seconds for sibling, and 8 seconds for child items, invariably; of course this broke external macros of mine relying on fast item creation.

After compact-and-repair, which, as expected, did not "compact" the db as for its 0.6 gb size since what had been in the db had remained in it, item creation time went back to normal, so it seems that "item moves in numbers" create lots of overhead which then can be discarded again by "compact-and-repair".

Thus, avoiding it, as I had done for the above reason, obviously is counterproductive.
Reply With Quote