Extreme slowdowns with setRoomArea/resetRoomArea

All and any discussion and development of the Mudlet Mapper.
Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

I'm having a slight problem with using the above commands - They're slow to run. This is on windows 10/ 3.0-delta

Either command executed on a room held in the other area (to or from -1) seems to take a half second or so to run: Enough to be a slight lag when moving through rooms realtime, or a terrible lag if speedwalking through multiple rooms.

I took a quick look at the source on github, and i'd guess this is likely occuring in determineAreaExits - The full map file has around 10k rooms in it right now, the majority held in the -1 area. I haven't read enough of the code yet to be sure what the function is for - Is it something that needs to be run on the -1 area? I would consider it to be an area that players shouldn't actually be able to enter/or exit: If they enter a room in the unassigned area, that room gets assigned to whatever area they're actually in.

This likely would be also why running my version of the cmud import script takes so long (4+ hours) - All rooms when imported are being place in the unassigned (-1) area, which is getting extremley large.

By default, I keep all rooms held in the unassigned area locked from speedwalk. A player can't enter or exit the area, speedwalk paths can't pass through it, etc. I don't know if it would cause problems for anyone elses maps, but is it possible to throw an 'if' in there, and not perform determineAreaExits() on the -1 area (whether it's source or destination)? It might effect the speedwalk algorithm for maps that do allow passage through the -1 area.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by SlySven »

That TArea::determineAreaExits() is a known bootleneck for maps with areas with big (>5K say) room counts and I have a fix in the pipeline that speeds up stuff in this area - it is happening because each area has a needed container that records the rooms that are in the area. When a room is moved/added checks have to be done that mean looking through that container several times to see if the rooms on the other end of the exits are in the same area IIRC; unfortunately the current choice (QList) means that to establish if a room number appears in that list every entry must be examined i.e. an operation of order O(n) which is proportional to the number of items in the container; a pending change will change that to a hashed type container (QSet) which makes checking to see if a room number is in it a one-time operation i.e. of order O(1), a constant time operation. I have a test map that has 2,330,079 rooms and even with my new PC system it takes forever to load with current code - but only a few seconds with the modifications (though then it starts to use some memory swap space as my physical 8GB ain't enough!)

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

Thanks, sounds like it's something that's been previously run in to. Combined between the map i'm using at this time (>10k rooms), and my extensive use of the -1 area, it's quite noticeable.

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

I'm at 21,000 rooms now in my included map, and really running into issues with the described slowdown. In pipeline, great. What are the chances of any time soon this map change moving in to the development branch/ and even better the next mudlet release?

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

I've submitted a bug report on this:

https://bugs.launchpad.net/mudlet/+bug/1500927

I've also attached a short video of the effect of it, i'd attach it here as well except .avi files aren't allowed

Thanks

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

I'd noticed pr301 enroute for this. Thanks! I'd split my map into a half dozen files, with none over 10k rooms - It would be nice to be able to recombine them back to a single file.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by SlySven »

Tweaked PR301 (development) and ported to PR308 (release_30) - so should be better now.

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

I've started looking at this - Couple things that have popped up so far

1) Creating a new room (which would be placed by default in -1 to start) throws an error.

addRoom( 1096 )
[MAP ERROR:]AreaID=-1 does not exist, can not set RoomID=1096 to non-existing area!

2) I can address, but it appears that any room without a defined doorname has the door deleted. My code at least was defaulting any doors/no name to a name of 'door'

[ INFO ] - In room with Id: 80033 found one or more surplus door items that were removed:
south (closed).

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by SlySven »

1) That is a niggle, I think the room will get set to area -1 anyway (the default or "holding" area) but I'm not entirely sure that that area is displayable, then when it is saved and reloaded it gets "fixed" into that area unless you have placed in into a normal area. BTW To return a room to that area afterwards you have to use "resetRoomArea( roomId )". I'll take a look at it to clean it up...

2) You now have to have an actual exit (or a stub) in a particular direction before you can have a door in that direction. That warning is advising you that there was a door (of type closed - i.e. drawn in orange) in room 80033 which was set on a south exit direction but that there was not a south exit or exit stub and so it was removed. Any "name" allocated to a door is probably handled as a roomUserData item that a script package does something with. (For instance I have a map for a MUD that I play that did store a name that the MUD requires you to use to open or close some doors as a plain direction string as the key {e.g. "s"} and the name as the value {e.g. "OriganGate"}, I revised the scripts to my own tastes to be a bit more specific so that now it uses "doorName_s" but that is entirely a script thing and not something that this revision would even know about - let alone break...!)

Nyyrazzilyss
Posts: 334
Joined: Thu Mar 05, 2015 2:53 am

Re: Extreme slowdowns with setRoomArea/resetRoomArea

Post by Nyyrazzilyss »

You're correct, the error thrown on room creation isn't actually a big issue - I was in the process of reimporting all my maps into a single map file when all those particular errors got thrown, however, i'm the only one that should ever see them/only when i'm building the original map files anyways.

2) I'll recheck once the large mapfile has been rebuilt (I had to do it on -delta, one of the two errors above caused the import to abort after a single room so it's going to probably take overnight), however, I would swear it was removing rooms that had doors and full exits, just null door names - It gave -a lot- of them listed when it loaded my -delta map files.

Thanks btw! It's going to make a huge speed difference on my script :)

(edit)

Still going back and forth between delta and dev with rebuilding my map from the cmud source - Looks like part of the difficulty I was having where it was stopping import after a single room is getRoomUserData is returning nil on non-existent keys (where it used to return ""). Minor change on my side to make that work.

Post Reply