Zugg Software :: View topic - [3.29b] Deleting rooms through Mapper Spreadsheet view very slow

Posted: Mon Sep 27, 2010 2:22 am

I'm using the spreadsheet view to delete otherwise invisible/unselectable rooms. It takes about 40 seconds for each room on a state-of-the art computer built earlier this year. I have 20k+ rooms, but still, why is it taking this long to delete each room? Has anyone else tried this to perhaps provide a comparison?

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

It's because the spreadsheet view probably isn't filtered. When dealing with the entire mapfile, every computer is going to be really slow because essentially CMud's using all the memory it can in one operation.

As for your rooms, I know you're no stranger to working with the mapfile directly, so have you gone looking to see if some of the default properties are again not set correctly? Or, if you didn't want to do that, has this mapfile gone through the version 1.3 MapConverter? That version was released in order to fix a wrong-value default property (in SQL, the difference between TRUE and not zero is important) several versions ago, and it sounds like either you stumbled onto that bug or it came back or perhaps there's a new one.

Posted: Mon Sep 27, 2010 3:55 am

I haven't run it through any tools outside of Cmud since 2008 or whenever I wrote cmud_map_doctor. I've also never run any version of the MapConverter on it. It's worked perfectly fine in all aspects in the intervening time since I ran it through my own utility (now quite a while ago).

Which wrong-value default property are you speaking of? It doesn't sound like anything I would have been messing with, but now you have me worried.

Posted: Mon Sep 27, 2010 4:00 pm

I think I found the topic about the conversion utility. From everything I understood from that topic I don't believe that to be the case here. I neither ran the conversion utility nor did my own utility do anything like what Zugg was doing with his. My utility was primarily concerned with renumbering, not with messing with columns. I simply updated numbers and deleted rooms and links that were incorrect or orphaned.

Speaking of which, with the recent advent of widespread vNum usage, people should *not* use my script. I never accounted for vNums since they weren't available for use when I wrote it. The script automatically sets the vNum to the actual key number (as is proper with a vNum that isn't meaningful). I could probably re-write it to look at the new field Zugg added, but by default it will obliterate any vNum's in the map.

Wizard Joined: 22 Mar 2007 Posts: 2320

If I recall correcttly, the wrong-value default property was caused by an older beta version, so your map could have the problem even if you never used the conversion utility. The conversion utility will fix the problem if it is present. If you are still getting those rooms with empty values (and thus invisible), your map probably has the problem and should be run through the converter.

Posted: Mon Sep 27, 2010 5:20 pm

You're mixing issues a little bit here... I have a separate topic talking about the invisible rooms. This topic was simply addressing the speed of the delete operation in the spreadsheet view.

However, I see the invisible rooms from a clean setup using 3.29b. I posted how to reproduce it without any pre-existing map; just loading cmud 3.29b and opening a brand spanking new map.

So I don't know if there is some link between the invisible rooms and the speed of the delete, but my initial assumption is that they are separate. Regarding invisibility, I think that while prior bugs could cause the invisible room issue, it is also definitely caused by a current bug as well.

Posted: Mon Sep 27, 2010 7:40 pm

The spreadsheet view is slow because it is an un-optimized raw database view of the mapper database. Updating anything in the mapper causes this database view to refresh and I have not spend any time trying to optimize it, and won't be able to get to that before the public release, sorry.