Forum Discussion
Arti-G
Jun 12, 2024Copper Contributor
Edge Workspaces sync BUGS
Hello First of all, I think that Workspaces in Edge is a very useful feature! Edge also has vertical tabs, which makes it the best tool for researchers using hundreds of tabs. I think other browsers...
Arti-G
Jun 14, 2024Copper Contributor
Somehow Edge is not frozen now, not doing hardcore writes to SSD, so I checked logs and compared old (frozen) to current log (working ok).
Not frozen:
2024/06/14-01:23:19.445 8b00 Compacting 4@0 + 2@1 files
2024/06/14-01:23:19.471 8b00 Generated table #594894@0: 24741 keys, 2108148 bytes
2024/06/14-01:23:19.491 8b00 Generated table #594895@0: 39630 keys, 804534 bytes
2024/06/14-01:23:19.491 8b00 Compacted 4@0 + 2@1 files => 2912682 bytes
2024/06/14-01:23:19.492 8b00 compacted to: files[ 0 4 7 0 0 0 0 ]
Frozen 1:
2024/06/12-13:14:19.485 1a570 Generated table #365187@0: 40283 keys, 2109396 bytes
2024/06/12-13:14:19.485 1a570 Compacted 8@0 + 1@1 files => 2109396 bytes
2024/06/12-13:14:19.488 1a570 compacted to: files[ 4 6 7 0 0 0 0 ]
Copilot says:
Comparing the two logs, there are a few differences that might have contributed to the improved performance:
Number of Files Compacted: In the second log, 4 Level-0 files and 1 Level-1 file were compacted. In the first log, 4 Level-0 files and 2 Level-1 files were compacted. This means more data was being processed in the first log, which could potentially lead to better organization and faster access times.
Number of Keys and Size of Data: In the second log, one table was generated with 40,283 keys and a size of 2,109,396 bytes. In the first log, two tables were generated with a total of 64,371 keys and a combined size of 2,912,682 bytes. The distribution of keys across multiple tables and the larger total size of data could potentially improve the performance of read operations.
- Number of Files After Compaction: In the second log, there were 4 files at Level-0, 6 files at Level-1, and 7 files at Level-2 after compaction. In the first log, there were no files at Level-0, 4 files at Level-1, and 7 files at Level-2. Having fewer files at Level-0 and more files at Level-1 could potentially improve read performance, as LevelDB tries to minimize the number of Level-0 files due to their overlapping key ranges.
Frozen 2:
2024/06/13-11:56:15.168 7118 Compacting 4@0 + 1@1 files
2024/06/13-11:56:15.425 7118 Generated table #542179@0: 64278 keys, 1575665 bytes
2024/06/13-11:56:15.425 7118 Compacted 4@0 + 1@1 files => 1575665 bytes
2024/06/13-11:56:15.558 7118 compacted to: files[ 0 3 7 0 0 0 0 ]
Copilot says:
Comparing the two logs, there are a few differences that might have contributed to the improved performance:
Number of Files Compacted: In the second log, 4 Level-0 files and 1 Level-1 file were compacted. In the first log, 4 Level-0 files and 2 Level-1 files were compacted. This means more data was being processed in the first log, which could potentially lead to better organization and faster access times.
Number of Keys: In the second log, one table was generated with 64,278 keys. In the first log, two tables were generated with a total of 64,371 keys. The distribution of keys across multiple tables can potentially improve the performance of read operations.
Size of Data: The total size of the data compacted in the first log is larger than in the second log. This could indicate more efficient packing of data.
Number of Files After Compaction: In the second log, there were 3 files at Level-1 after compaction, while in the first log, there were 4 files at Level-1. Having more files could potentially improve read performance, as it’s easier to locate data spread across multiple files.