aertslab
Refactor loom file handling
Separate functions should be generated for switching modes, deleting out of date search spaces and updating hashes
Further, per the discussion in Slack: James Collier: Hey guys. I'm not convinced why Loom connections need to be maintained between requests. Is there a good reason for this? Is opening a connection an expensive operation?
Kris: Good question. I'll check.
Max: Opening a loom connection is quite fast nothing should be preloaded ; but I think we stored it because for each operation on a loom file you need a connection so make sense to open it once right ? Why are you concerned about that ?
Kris:
In [18]: %%timeit
...: open_and_close_loom(loom)
3.36 ms ± 15.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
James Collier: Ok great!
Kris: And that's a larger loom, ~200k cells
James Collier: if you need to maintain connections you have all of this overhead code to ensure they're not shared and who can access etc. Well, all of that is unnecessary if you don't need to keep the connection around
Kris: We still need that no? In case of concurrent reads/writes
James Collier: In case of concurrent reads/writes In the case for writes only
Kris: OK true, but we'd still need some kind of lock in place, to prevent a write during a read operation
James Collier: So indeed, we can't get rid of everything, we still need to track writes. But I think that simplifies the logic dramatically