mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-04-26 01:35:08 +02:00
14dc9e8ca2
remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.