MT 1.3b62 Progress

[plothos]

No doubt a lot of the problems are framework-related, but even those aren't to be blamed on the framework, per se, if they run far better on b56 than b61.

[Hawke]

What are the numbers showing exactly? What is high?

Just fired up a campaign and did a move,
Timer zonerenderer: 47
labels: 42
tokenlist-1.1: 44

Not sure -didn't seem too bad. Maybe this is ripe for a guide to help figure some stuff out? How hard would it be to include macro stuff here?

Interestingly I'm not seeing anything posted when I drop the tokens (hit "D") and that's where the slowdown is. The individual moves over and selects all show stuff.

[Rumble]

The one thing it doesn't rack though is macro related stuff. I wish it did because I am starting to think that it might be some of the frameworks that may be killing performance - but that is just a gut feeling, nothing substantial.

It could be that frameworks or macros are somehow to blame, but as mentioned, in two identical campaign files (identical with the exception that one opens in b61 and the other in b56; I don't know what changed in the .cmpgn structure, if anything) I observe a large difference in execution speed.

Perhaps there's some commonly used function that's now bottlenecking due to some change; it could certainly be an unintended consequence of a change in MT. I don't know if it uses a genuine parser, but maybe there's some ambiguous element in the macro code that's now taking a long time for the parser to resolve.

[dorpond]

What are the numbers showing exactly? What is high?

I start seeing slowdown when the numbers get around 200+ (total, not each value).
But mine are mostly because of Lighting and VBL related stuff.

[Azhrei]

What are the numbers showing exactly? What is high?

I start seeing slowdown when the numbers get around 200+ (total, not each value).
But mine are mostly because of Lighting and VBL related stuff.

Yeah, the only things the numbers are tracking is the image rendering. That means the background map, objects, tokens, fow, VBL (if you're on the VBL layer), text, drawings, and so forth.

I've seen the same slowdown Hawke has. I don't think it's framework-related as moving a token from point A to point B doesn't involve anything in the framework (macros or any of that).

I'm guessing is an inefficiency of the drawing routine. For example, you drag the tokens and let go and it goes back and recalculates the A* path over and over, once for each token, when the pathing had already been done so that it could be displayed. Or perhaps it's the process of moving the tokens -- longer drags seem to have a larger lag, so perhaps MapTool is moving each token each step, then moving it again for the next step, and so forth. That might have happened when the code was added to prevent players from dragging tokens into an area of VBL, back around the mid to late 40's. Or perhaps it's related to fow exposures at each step of the path being taken? (Note that MT is necessarily doing that, but the code may not be optimizing it correctly.)

[plothos]

I've seen the same slowdown Hawke has. I don't think it's framework-related as moving a token from point A to point B doesn't involve anything in the framework (macros or any of that).

With some macros like DeviantNull's 4E character sheet, or the one I've got in my framework, which refresh frames full of HTML and macrolinks upon selection change, the lines here get rather blurred. But we certainly are seeing problems independent of such framework elements.

[Rumble]

I'm guessing is an inefficiency of the drawing routine. For example, you drag the tokens and let go and it goes back and recalculates the A* path over and over, once for each token, when the pathing had already been done so that it could be displayed. Or perhaps it's the process of moving the tokens -- longer drags seem to have a larger lag, so perhaps MapTool is moving each token each step, then moving it again for the next step, and so forth. That might have happened when the code was added to prevent players from dragging tokens into an area of VBL, back around the mid to late 40's. Or perhaps it's related to fow exposures at each step of the path being taken? (Note that MT is necessarily doing that, but the code may not be optimizing it correctly.)

The code for rendering movement sets was changed somewhere between b56 and b61 (I know this because I worked on movement limiting in the b56 code, and all that stuff is different now) - the changes don't strike me as anything that would cause a problem, though; it looked mostly to be code consolidation/reorganization. And, it wouldn't have anything to do with macros, as far as I know. However, it did get changed, and maybe there are some unexpected effects.

[jfrazierjr]

The one thing it doesn't rack though is macro related stuff. I wish it did because I am starting to think that it might be some of the frameworks that may be killing performance - but that is just a gut feeling, nothing substantial.

I have no doubt about that and PM'ed Trevor about those suspicions the other day and got a positive reply back. Basically, every time the token properties are changed there is a round trip to the server and back out to all clients. So if you have a single macro that changes 5 token properties, that is 5 round trips NOT 1. This is because of the original macro implementation and the way tokens were designed made an assumption that there would be no major changes. With the new macro code added, tokens (properties and actual macro's code) can be VASTLY larger than they would have been a year ago... then consider moving in those changes to the model multiple times and yea.. it can cause a lot of slow down...

I currently use Veggiesama's framework... I would like to change it to store the properties and macros on a lib token instead, but really don't have the time to make such large changes... Plus, I hope this can be fixed fairly early on in 1.4 and since I only game once a month, it may not be worth the time taken..

[plothos]

Hmmm, does this mean that a framework that stores, say, all a weapon's data in a json in a single property will be faster than one that stores it in several properties, because while unpacking jsons may be more work than referenceing properties (don't even know if that's true), you only execute this round trip once when updating the tokens?

Is something like this related to why it seems changing token states is ridiculously slow for some reason?

[Rumble]

Jfrazierjr, that makes some sense, but does it account for explains the same code running faster between two versions? Unless a change to macro processing happened between b56 and b61 - that is, a change beyond the addition of new functions - it should be the same number of trips to and fro in 56 and 61.

I have the same framework - my version 4.20 D&D framework, which was was brutally slow in b61 - cranking along at around 4x the speed in b56, with no changes except versioning. That framework, btw, stores almost all of the actual code on the Lib:token, but tokens themselves have a bunch of properties.

[plothos]

I think it could. If the same framework sends a bunch of updates that all have to cycle through the route he describes, then if one version does it slower, or if one version sends updates less frequently, you'd have one framework with performance hits far greater on the cumbersome MT version.

Or am I misunderstanding what one of you is saying?

[Rumble]

I think it could. If the same framework sends a bunch of updates that all have to cycle through the route he describes, then if one version does it slower, or if one version sends updates less frequently, you'd have one framework with performance hits far greater on the cumbersome MT version.

Or am I misunderstanding what one of you is saying?

What I took from jfraz's comment is that since there's a round-trip between server and all clients to make a property update, framework design is an issue, since something that was designed with more property changes/accessions would have a lot more round trips between server and client and thus may take longer (so the burden is on the macro writer to strike a good balance).

You and I appear to be on the same wavelength though - while macro use has grown beyond initial predictions, there seems to be something internal to MapTool that's making the same macro code take longer to run.

[plothos]

What I took from jfraz's comment is that since there's a round-trip between server and all clients to make a property update, framework design is an issue, since something that was designed with more property changes/accessions would have a lot more round trips between server and client and thus may take longer (so the burden is on the macro writer to strike a good balance).

Right, hence my question to him, above.

Yeah, I think we are on the same page. I was just thinking also that it might be that the changes within MT, if they are relative to these property-change round trips somehow, might still show up more for some frameworks (or functions within frameworks) than for others, even though, arguably, the problem lies within MT, at least in large part.

[thecyberwolfe]

Just to throw more weird on the fire here...

Just got done with tonight's game, running a Veggie template in b61. Game started out with the slow macro runs and movement updates, but about an hour in, things mysteriously sped up again - not as fast as it should have been, but faster than it was. Kind of in the middle I suppose.

This is a face-2-face game, run on my laptop (Win7 Ultimate, 2GB RAM) using a second instance on a second monitor.

[Rumble]

Just to throw more weird on the fire here...

Just got done with tonight's game, running a Veggie template in b61. Game started out with the slow macro runs and movement updates, but about an hour in, things mysteriously sped up again - not as fast as it should have been, but faster than it was. Kind of in the middle I suppose.

This is a face-2-face game, run on my laptop (Win7 Ultimate, 2GB RAM) using a second instance on a second monitor.

If I remember something Craig's talked about before correctly, Java has a "Just in Time" compiler that can do some optimization of tasks when it sees the same thing being done over and over again. So it's possible the speed up comes from that (thinking back, I've seen the same sort of thing with my frameworks - it'll start of slow, but pick up speed at a certain point).

I may be misrepresenting what JIT compiling does, but that's how I understood it.