https://bugzilla.wikimedia.org/show_bug.cgi?id=73611
--- Comment #5 from Tisza Gergő <[email protected]> --- The slowness of limn is a major usability problem; if we are going to use it for a long time, I think it's important to improve it. My understanding is that it is going to be replaced soon-ish, though, in which case I don't think it's worth spending time on fixing it. (Also, I don't know how much the lack of caching contributes to the performance problems, although the 20 sec request linked by Nemo sounds pretty bad.) As for implementing caching, retrieving the data does not seem to be much of a performance concern. In the network log linked by Nemo, only the last request (the tsv file) contains actual data; all others are limn configuration files. Those are always local so limn could just use their last modification date as a cache-buster string. I don't think it is a big deal to leave the tsv file uncached (it is generally updated once a day, but when working on the dataset-generating code, not being able to see updates immediately would be a major inconvenience), although maybe the cache buster could be removed so that normal ETag- or Last-Modified-based caching works. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
