* perf: Reduce impact of forced cache replacement on every doc access
* fix: clear cache before processing users
Note: This is just an artifact of testing model, this won't have any real
effect on execution in real system.
Basically `enqueue_on_commit` is not respected in tests and it can't be
practically supported either.
Sometimes we get invalid flags from `imap.uid()`, like `[b'System Error (Failure)']`
This leads to the flag getting parsed as 83 (`ord('S')`)
Signed-off-by: Akhil Narang <me@akhilnarang.dev>
- Eagerly initialize request_cache, all requests use it, so what is the
point of doing it lazily?
- Reduce accesses to `frappe.local` namespace, get cache once and reuse
it in rest of the execution.
Before: 1250ns +/- 1%
After: 645ns +/- 1%
Source: Trust me bro.
(no really, for now just trust me or look at the diff)
* perf(site_cache): reduce access to frappe.local namespace
This change also allows calling @site_cache during init, as long as `site` parameter is set.
* test: frappe.init patching
* perf: use monotonic time instead of realtime for eviction
datetime is complex, slow and not really required for this use case.
* perf!: Drop support for unhashable arguments
Just like LRU cache, no need to support unhashable types in site_cache.
Current usage in codebase also shows that it's not required and json.dumps is quite slow.
Just like LRU cache, no need to support unhashable types in site_cache.
Current usage in codebase also shows that it's not required and json.dumps is quite slow.
`get_doc` is single most used commands, directly and indirectly.
Currently there's QB overhead of building queries.
These queries are SO SIMPLE, I don't believe we need QB to keep these
maintainable or compatible with databases.
Microbenchmarks (first is simple flat document, second has many child tables):
```
bench_orm_bench_get_doc: Mean +- std dev: [before] 10.7 ms +- 0.2 ms -> [after] 7.24 ms +- 0.15 ms: 1.48x faster
bench_orm_bench_get_user: Mean +- std dev: [before] 16.3 ms +- 0.2 ms -> [after] 9.50 ms +- 0.14 ms: 1.72x faster
```
* fix: Don't cache anything hashable
If filters are list or dict then they aren't hashable, there was little
reason to do this IMO.
If something is indeed cacheable then where is the eviction for it?
simple k:v is only thing we can realistically cache here.
* ci: Dont specify client version
Clients work on mysql protocol ABI which works for huge ranges of
servers.
If filters are list or dict then they aren't hashable, there was little
reason to do this IMO.
If something is indeed cacheable then where is the eviction for it?
simple k:v is only thing we can realistically cache here.
Small change on top of https://github.com/frappe/frappe/pull/28740
Reason: Site with many many users might still have huge # of rows being
returned. E.g. FC.
This just makes UX slightly bad, but there's easy workaround for it.
Users can just apply this filter -> "Owner = Self", whether users know
it or not is a different question.
