For me, as a comparison, I will (eventually) get a map for all of Texas's routes, and there are more miles in Texas than Kentucky.
If I try to upload just state routes for Kentucky (instead of interstates/Parkways/US/States combined) it does not load for me.
Don't know if that means anything for any of you.
The number of segments probably means more than total miles for rendering time.
A better quick-n-ditry indicator of number of waypoints, and thus number of segments, would be the total filesize of all WPTs in the region. I have 1.3 MB for TX, and 1.6 MB for KY. So KY is "bigger" but still in the same ballpark.
I think the csv order enhancement slowed the SQL query time for large maps.
"draw the polylines only once" feature thread. I forget the exact fix here -- was it removing/erasing the lower-tiered polylines before drawing the higher-tiered polylines over top?
Though, it seems the CSV ordering feature may be the bigger hit...
For what it's worth, I can load up http://travelmapping.net/user/mapview.php?units=miles&u=osu_lsu&rg=KY and get a very usable map in about 77 seconds. So that leads me to believe it's not the SQL query, which is a server-side cost, but the client-side browser resources (RAM, hardware graphics acceleration) that causes the failure for the OP. For me, this is on a 2016 Mac Book Pro, latest Firefox, 16 GB memory.
About exactly my experience here. A usable map in 77 s. The first 73 seconds were just my browser waiting for the server-side magic to happen; after that I saw my network usage spike, shortly followed by the table and map rendering. Once loaded, I can zoom and pan easily with almost no lag. UbuntuMate 16.04 + Firefox 62.0 (which AFAIK isn't especially hardware-acceleration friendly?). RAM usage went from 1.1 GB before loading my mapview to 1.3 GB after.
