View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002197||1 - Backlog||Bug||public||2017-08-11 17:24||2019-11-01 10:29|
|Summary||0002197: Logbook open and close performance is slow|
|Description||The loogbook application stores records in memory, after reading them from the database. It does so with an egregiously bad data structure. If we imagine each record as a set of values for each column, we can think of each of those values as a “cell”. The value of the “call sign” cell in record #6 might be “K7ZCZ”, while the value of “Frequency” in record 102 might be “14.313.000”.|
The logbook has about 120 columns that are visible to users; it maintains about 225 columns internally. Thus, each row has 225 cells. If you’ve got a logbook with 60,000 QSOs in it, the logbook is managing values for 225 * 60,000 == 13,500,000 cells.
The problem is that these cells are each managed as individually allocated or freed bits of memory. Some work was done to eliminate null, empty, or zero values; but in my testing, a 60,000-row logbook still allocates more than 4 million individual blocks of memory.
|Steps To Reproduce|
1) We have a 60,000-entry logbook for testing. Import it.
2) Close it. Takes about 50 seconds
3) Open it. Takes about 35 seconds.
|Tags||No tags attached.|
|2017-08-11 17:24||K7ZCZ||New Issue|
|2017-08-11 17:28||K7ZCZ||Relationship added||related to 0002062|
|2017-09-07 15:59||K7ZCZ||Relationship added||related to 0001332|
|2017-09-07 22:31||K7ZCZ||Note Added: 0004134|
|2017-09-07 22:31||K7ZCZ||Assigned To||=> K7ZCZ|
|2017-09-07 22:31||K7ZCZ||Status||new => assigned|
|2017-09-18 00:14||WA9PIE||Project||3 - Current Dev List => 2 - Next Dev List (Holding Area)|
|2019-06-15 11:30||WA9PIE||Project||2 - Next Dev List (Holding Area) => 1 - Backlog|
|2019-11-01 10:29||K7ZCZ||Relationship added||related to 0003535|