From 7c5e9af654ed16b38b6f02c947e5aa6f7c5d6b9f Mon Sep 17 00:00:00 2001 From: masklinn Date: Sun, 5 Apr 2026 17:33:40 +0200 Subject: [PATCH] Update docs for #302 Since all resolvers are now cached, the original example doesn't work anymore. Also some wording changes around. Fixes #305 --- doc/guides.rst | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/doc/guides.rst b/doc/guides.rst index 9ea323e..63a8101 100644 --- a/doc/guides.rst +++ b/doc/guides.rst @@ -93,10 +93,9 @@ composing :class:`~ua_parser.Resolver` objects. The most basic such customisation is simply configuring caching away from the default setup. -As an example, in the default configuration if |regex|_ is available -the regex-based resolver is not cached, a user might consider the -memory investment worth it and want to reconfigure the stack for a -cached base. +As an example, all resolvers are cached with an +:class:`~ua_parser.caching.S3Fifo` of size 2000, a user's workload +might lead them to favor a larger LRU. The process is uncomplicated as the APIs are designed to compose together. @@ -112,7 +111,7 @@ the relevant :class:`Matchers` data:: The next step is to instantiate the cache [#cache]_ suitably configured:: - cache = ua_parser.Cache(1000) + cache = ua_parser.caching.Lru(10000) And compose the base resolver and cache together:: @@ -136,6 +135,11 @@ from here on:: :class:`~ua_parser.caching.Local`, which is also caching-related, and serves to use thread-local caches rather than a shared cache. + Although this does not remove the cache locks it avoids contention + on the locks, which can be useful when using a free-threaded + interpreter, especially when using the LRU cache as it has to + synchronise on hit. + .. _builtin-resolvers: Builtin Resolvers