Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Message
| I would be looking at what you are trying to do to get this "extremely slow" response.
Just as an example, using the client setup I got from you SVN repository, I turned on GMCP debugging, and turned off triggers, and then "runto weather" to see what was being pushed through. For each room, I saw something like this:
East Windy Mountains (272)
<MAPSTART>
East Windy Mountains
^ ~ ^ ~ . , . , ^ ~
^ ~ ^ ~ ^ ~ ^ ~ ^ ~ ^ ~ ^ ~
/ \ ^ ~ / \ ^ ~ / \ ^ ~ ^ ~
/ \ / \ / \ /#\ / \ / > ^ ~
/ \ / \ / \ / \ / \ ^ ~ ^ ~
^ ~ / \ / \ / \ ^ ~ ^ ~ / \
~ ~ ^ ~ ^ ~ ~ ~ ~ ~
[ Exits: N E S W ]
<MAPEND>
room.info { "num": 18443, "name": "East Windy Mountains", "zone": "gelidus",
"terrain": "icemount", "details": "",
"exits": { "n": 18383, "e": 18444, "s": 18503, "w": 18442 },
"coord": { "id": 2, "x": 52, "y": 21, "cont": 1 } }
char.vitals { "hp": 1015, "mana": 1147, "moves": 272 }
Now for a start, you are sending 22 lines of map data (<MAPSTART> through to <MAPEND>) per room. That's 22 lots of:
- Processing incoming TCP/IP data
- Decoding ANSI colours
- Trigger matching
- Inserting line into output buffer
- Calling a script to save that line in a table
- Omitting that line from the output buffer
Done per room.
Then on top of that you get the GMCP data which effectively gives you a lot of the same information again (room number, exits, terrain type, whether there are shops).
So that is duplication basically. Duplication that takes time to process. Surely you can amend the GMCP information enough to not need the old <MAPSTART> stuff?
Then there is the room info (room.info). Now every time you visit room 18443 you send the name, zone, terrain, exits, coordinates. More duplication. More processing time.
I argued at some great length on the Mud Standards forum in favour of some sort of caching scheme. Didn't get much support, got a lot of lengthy posts explaining why I was wrong.
The point was, before even making those posts I had noticed this duplication of data, and was trying to alleviate it.
Let's say, instead of:
room.info { "num": 18443, "name": "East Windy Mountains", "zone": "gelidus",
"terrain": "icemount", "details": "",
"exits": { "n": 18383, "e": 18444, "s": 18503, "w": 18442 },
"coord": { "id": 2, "x": 52, "y": 21, "cont": 1 } }
you just sent:
room.info { "num": 18443 }
And then if you knew all about room 18443, then fine - you can instantly display it. If not you request the details about room 18443. Might be slower the first time. Would be faster every other time.
My other comment is that your idea of "extremely slow" and mine don't necessarily coincide. Last time I showed that I could move about 60 rooms in something like 19 seconds, which I thought was quite fast. You said it was far too slow and your players wouldn't accept it. Well, perhaps some player re-education is called for. You can have fast response time and a text-based interface, or slightly slower response with maps, spellups, status bars, chats windows etc. Or there was even the hybrid we discussed where you turn some features off when running around doing a speedwalk.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|