I took a look into the code and most of the tab reordering is inefficent as related tabs are also reordered (even in the case of a new tab added to the end of a list) I checked up and this is a known issue with a suboptimal architecture (its actually a hangover from the very early days of dotnetnuke/ibuyspyportal). Clearly this inefficency is not noticed by most people who only have a handful of tabs per parent, but if you have thousands that's what you're seeing. I'd suggest logging a bug request to say that sites with lots of tabs suffer slowdowns -even though its known to the engineers, logging it brings it to the attention of the QA and business people who ultimately decide what get's worked on. As to your issue, all I can think to do is suggest you either change to a module that uses its own table - or else rework your code so not all items are put under the same parent tab (in theory you could make them all level 0 items [obviously marked as not included in the menu] which would make the tab hierarchy wide rather than deep but the tabordered code would work quickly as there would be no sibling tabs.

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US

its likely caused by other traffic running queries agains the tab's tables that lock escalation or serialised queries (note: by other queries it could be as simple as users logging in and out causing the tabcollections to be built up to determine their menu structure)

---

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US

Hi Cathal

Where can I report this as a bug ? is there any website or can I reply to the issue you mention is already on the bug tracker list?

Thanks