Re: MapTool 1.3 Final, patch02 (build 85)
Posted: Thu Apr 07, 2011 3:44 pm
TMI.MageMirin wrote:my win7x64 ultimate (pyr8 edition) system
TMI.MageMirin wrote:my win7x64 ultimate (pyr8 edition) system
Thanks.suntzu777 wrote:i found it very laggy only when i started the server , if i didn't start the server there didnt problem , this is running on osx 10.6.7 with 8 gig and 4 x i7 pro's so went back to r84 and everything was fine
Wow. At least that implies that the problem is at the network layer. (Can you test it by resetting the fog, too? I'm just curious.)Rumble wrote:[...] and OMG LAG with the server running
Azhrei wrote:Wow. At least that implies that the problem is at the network layer. (Can you test it by resetting the fog, too? I'm just curious.)Rumble wrote:[...] and OMG LAG with the server running
It likely has something to do with objects being serialized before sending over the network and with the server running, the local client does all of that same work when talking to the server that's running in the background. An obvious optimization is not to serialize it when talking to 'localhost', but that wouldn't help with players connected...
Well, note to self: don't put 5 levels of very complicated VBL on a single map!
*Grins at Azhrei*Azhrei wrote:This is likely the last update for MT 1.3.
It sounds like there's some problem with the client/server connection. But the clientserver project (an RPTools library which MapTool uses) hasn't had any changes to it that I know of.aliasmask wrote:I made a macro which runs very quickly on the local machine, but propagating to the client computers takes forever.
the campaign file is a game which has been running for a few months using rumble's framework , there are alot of monsters , rooms with vbl , the campaign file is about 45 megAzhrei wrote:Thanks.suntzu777 wrote:i found it very laggy only when i started the server , if i didn't start the server there didnt problem , this is running on osx 10.6.7 with 8 gig and 4 x i7 pro's so went back to r84 and everything was fine
Which campaign file are you testing this with? The .rpmap I linked to or something else?
I can sort of understand the server thing -- obviously there's going to be network traffic. (Even without players. When you StartServer, MapTool creates a background job that runs the server and the MapTool application becomes a client to that server.) It just occurred to me that it could be that the map object (called a Zone in the code) is being sent when certain fields are being changed. I'll look into it.
Thanks again.
Actually, I'm still using b84, so it's not a new thing to b85. But I only recently created the macro, so the problem is new to me.Azhrei wrote:It sounds like there's some problem with the client/server connection. But the clientserver project (an RPTools library which MapTool uses) hasn't had any changes to it that I know of.aliasmask wrote:I made a macro which runs very quickly on the local machine, but propagating to the client computers takes forever.
I'm running a network capture right now to see if I can determine whether it's network related or something else.
Weird stuff. It appears that there are 1-, 2-, and 3-byte packets sent all the time. Apparently some kind of heartbeat or something. Images and other data are compressed and sent in large chunks (I mostly see TCP packets of 1024 bytes or 16332 bytes). I'm going to look into updating the Hessian library first (to see if the newer version is more efficient). If that doesn't fix it, I'll spend a little time profiling the network layer but something that fundamental may need to wait for 1.4.Azhrei wrote:I'm running a network capture right now to see if I can determine whether it's network related or something else.
As I would expect; we've made quite a few tweaks to the fog over the last few builds...dorpond wrote:- Performance does get a lot worse by just starting a server. For giggles, I also tested this in B82 and it was just as bad, if not worse, with this map.
Ah, I should've thought to check that. Thanks.- Doesn't seem to be VBL related because once I remove all VBL, the terrible performance doesn't change.
Thanks. I noticed that #47 showed up twice and that shouldn't happen. The CodeTimer is supposed to increment the value each time a new data point is created (although only data points of 10ms or more are reported). So two 47's shouldn't happen. I've fixed that bug.- As soon I imported the map, I switched to View as Player (moved a token) and performance got so bad that Maptool was virtually unusable:
[...]
- If I do the above tests after I completely fill in FOW, it is still pretty bad with 'view as player':
Timer ZoneRenderer.renderZone (60 elements)
2. calcs: 27 ms
45. tokens: 21 ms
47. tokenlist-7: 18 ms
47. tokenlist-1e: 754 ms
51. renderFog: 196 ms
55. renderFog:combined: 160 ms
56. renderFogArea: 33 ms
58. visionOverlayPlayer: 553 ms
Hm, good info. The GEA (Global Exposed Area) and TEA (Token's Exposed Area) have to be merged now each time a token is selected. I insisted Joe make this change as it's more accurate, but if it's going to be a performance problem we may have to change the way this works. (Joe: whenever a new zone renderer is made current we could start a new cache. If a token's fog is in the list we use it and bypass the renderFog() work. Keeping the cache current may be a pain though. I'll consider this as I look through the code.)- It doesn't seem to matter if the server is started with Individual FOW = On or Off - same results.
I believe the bold line is the problem. Unfortunately, profiling the code doesn't show enough detail to indicate which parts in particular are taking so long. I fear it's the merging of the various fog pieces though. That could be a problem. I plan to split the renderFog() method into small pieces so that hopefully the profiler can help isolate the issue.- Whew, view as player while a server is started - just another set of numbers for your viewing pleasure:
Timer ZoneRenderer.renderZone (59 elements)
2. calcs: 191 ms
45. tokens: 27 ms
46. tokenlist-1e: 8289 ms
50. renderFog: 4072 ms
54. renderFog:combined: 4049 ms
55. renderFogArea: 19 ms
57. visionOverlayPlayer: 4199 ms