[Skip] >> For long-running SpamBayes apps like pop3proxy and the >> Outlook plugin, pickles make sense if shared access to the scoring >> database is not needed. [Gregory P. Smith] > Combine that with data event/change logging and you have effectively > the same thing as what many apps think they need to use a database > library for. Replay the entire log of data changes internally on > infrequent app startup to generate your internal state. when the log > file is getting to big, write a full state snapshot and continue > logging changes from it. no need to save the entire pickle everytime > something changes. That may be OK for pop3proxy users. Alas, startup time and memory burden are keen topics for Outlook plugin users, and, e.g., the startup time to unpickle a large dict (let alone replay logs since the last snapshot) is unbearable for people with large training sets. When you start Outlook, it typically starts fetching email right away, and you typically want to see your email right away then. The relatively zippy startup time of a Berkeley DB is highly welcome for that reason.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4