Closed hjhawkinsiv closed 3 years ago
Graphs for map and page load times for the first 100 layers from most recent test run (Tue Nov 10 11:47:48 2020)
I committed the detailed console.log commenting from the screenshot for loading waypoint 24 in 516cb9f33716231d27c26dd93c8665249f456a00
Here's a super-easy repro!
Using Chrome, turn on your bookmark bar
Create bookmarks for waypoints 23 and 24. For me that's https://rsargent.earthtime.org/explore#v=40.46347,-79.92312,14.332,latLng&t=5.93&ps=50&l=bdrk,bdrk_detailed,total_race_2000,pgh_phh&bt=19600101&et=20191231&startDwell=0&endDwell=0 and https://rsargent.earthtime.org/explore#v=40.46511,-80.00675,11.29,latLng&t=1.62&ps=100&l=bdrk_subtle,pgh_nhbds_2010,anim_acs_renter_housing_costs_amt_2010_2017,pgh_new_apartment_units_bv&bt=19980101&et=20201231&startDwell=0&endDwell=0 but you'll want to customize to your own dev instance
Click back and forth between waypoints 23 and 24 on your bar. Observe that this changes the hash but doesn't reload the page -- same as the testing path. Observe it gets much slower after 5-10 iterations of clicking back and forth between 23 adn 24, and that the console log shows an increasingly long string of setVisibleLayers for each transition. (Ideally I think it should be calling setVisibleLayers only once per click?)
Should be resolved in commit 14f13e21086 Please confirm.
Updated measurements. Test now takes 21 minutes to produce screenshots, down from 55.
@hjhawkinsiv So page load time is significantly better now but still clearly increasing over time?
That would appear to be the case. This is what it looks like for golden:
I'll take another look. I was hoping it was the low hanging fruit I found, and while that did drop the load time by ~2.5X, something else is still at play...
I tried the bookmark bar 23/24 test from before. Here are the profile results.
On the 4th click (the 2nd visit to waypoint 24):
On the 40th click (the 20th visit to waypoint 24):
Some notable increases in time:
Is it possible we might be filling the DOM with unused elements and DOM operations are becoming slower?
Also, there was also a lot more grey "Task" time for the 40th click, but I don't know what it is.
@hjhawkinsiv Alright, take two. Pushed some more changes. Let me know how it goes this round. Seems significantly better for me.
New measurements. The overall time for generating the screenshots ~10 minutes. Map load times appear to also be significantly more stable across the entire test, with the only spike being Fires at Night, which is expected.
Wowee!!
On Thu, Nov 12, 2020 at 8:37 AM hjhawkinsiv notifications@github.com wrote:
New measurements. The overall time for generating the screenshots ~10 minutes. Map load times appears to also be significantly more stable across the entire test, with the only spike being Fires at Night, which is expected.
[image: image] https://user-images.githubusercontent.com/8990930/98946663-0365ac80-24a9-11eb-8ee1-ad29fd431299.png
[image: image] https://user-images.githubusercontent.com/8990930/98946410-b71a6c80-24a8-11eb-8f1f-d7b6b5340694.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CMU-CREATE-Lab/data-visualization-tools/issues/172#issuecomment-726082299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPJ44O6TUXUELEHY2W6BDSPPQKDANCNFSM4TQ4RY3A .
Looks like testing the top 100 on staging this morning (8am run) took only 9 mins 35 secs.
On staging as the test runs, the time between when the hash is set and when the page loads continually increases. The result being for the first 100 layers, staging takes ~4x golden to produce the screenshots.
Testing code:
Timing both of these lines separately:
Console log for loading layer 24
uicmp log for loading layer 24