Media registration has O(n^2 log_n) performance #30


Open
  • Cybeloras created this issue Feb 26, 2023

    Currently, rebuildMediaList is called every single time a new piece of media is registered. Then, inside this function it performs an O(n log_n) sort of the entire media list for that media type. This leads to some pretty major performance issues when bulk registering media, for example via the SharedMedia addon.

     

    Fix: At the end of lib:Register, replace the call to rebuildMediaList(mediaType) with mediaList[mediatype] = nil. The mediaList will then just be rebuilt the next time it is requested by a call to lib:List(), which probably won't be until a user opens a settings UI to do some configuration.

     

    This change reduced my loading times of the SharedMedia addon from ~1.8 seconds to 0.031 seconds, as measured by Warmup.

     

     

  • Elkano posted a comment Mar 5, 2023

    Nice catch and I agree that it doesn't make much sense to rebuild the data each time.

     

    However, your proposed fix would be a breaking change since currently the library always returns the same table. So if an addon is currently storing the returned reference it will stay up2date even after new media is added. And even though that isn't marketed as a feature, with the library being around for so long it's not unlikely at least some addon is (unintentionally) using that quirk.

    (Wiping the table and checking its length in addition to nil would help with keeping the same reference but since the table wouldn't be rebuild, yet, it would also break stuff.)

     

    I see a different possible solutions though, that would still improve the runtime though not as much as yours:

    exploiting that the list is sorted and thus doing a binary search and insert of the new value

     


To post a comment, please login or register a new account.