Ziechael said: Long continuous walls are supposedly better for performance when DL is in effect... I was about to say "I don't think that's true, they still have to do the same amount of DL processing," but then I thought "Hey, the path info is stored as a string, and JSON.parse is probably slow." I threw together a test case on jsperf.com, and parsing a single 5-element array (a rectangle) was almost twice as fast (916.6k ops/s vs. 471.8k ops/s) as parsing four 2-element arrays (straight lines). The difference goes down significantly when you add some slow processing (in my test case, a 10ms timeout for each of the four line segments), but the huge difference on the JSON.parse side still caused the rectangle parse+process to come out ahead (57.5k ops/s vs. 50.0k ops/s). When I tried a test case with only the processing and no JSON.parse, the rectangle still won out, but by a statistically insignificant margin (61.2k ops/s vs. 58.7k ops/s). I realize my "processing" is essentially the same for both test cases (four 10ms timeouts), but the same is true of the required calculations to figure out the DL for a single rectangle vs. four line segments forming a rectangle. The question then arises: does Roll20 store the path data in-memory as an array, or is it parsing the string each time the DL is calculated? If the former, then my initial gut instinct should be correct, there ought to be an insignificant difference (if any) between a single path forming some shape and a set of multiple paths forming the exact same shape. If the latter, then reducing the number of paths being used to form the walls on your map should significantly improve DL performance... and Roll20's DL processing should probably be changed to the former supposition to improve performance across the platform.
