You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we seek to a target entry's row and update the count / access time in-place.
If many entries are accessed, this can "fragment" the database, making the sort no longer be roughly one-pass O(n) and instead turn into O(n log n). (Tim sort's best-case complexity on partially sorted data is O(n).)
Possible optimization: Every once in a while, "defragment" the database with correctly sorted entries. This means that future frece prints (which read/sort everything) will be faster since the data will be already mostly sorted.
Downsides: increases code complexity, and I don't think it will benefit most users (including me). One alternative is running a manual frece print command to just write a new sorted database. :)
The text was updated successfully, but these errors were encountered:
Currently, we seek to a target entry's row and update the count / access time in-place.
If many entries are accessed, this can "fragment" the database, making the
sort
no longer be roughly one-passO(n)
and instead turn intoO(n log n)
. (Tim sort's best-case complexity on partially sorted data isO(n)
.)Possible optimization: Every once in a while, "defragment" the database with correctly sorted entries. This means that future
frece print
s (which read/sort everything) will be faster since the data will be already mostly sorted.Downsides: increases code complexity, and I don't think it will benefit most users (including me). One alternative is running a manual
frece print
command to just write a new sorted database. :)The text was updated successfully, but these errors were encountered: