Deployed def4f26 to wip with MkDocs 1.6.0 and mike 1.1.2

wip/404.html

@@ -12,7 +12,7 @@
 
 
       <link rel="icon" href="/assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/alternatives/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/changes/index.html

@@ -14,7 +14,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 
@@ -762,7 +762,15 @@ <h2 id="unreleased">Unreleased</h2>
 - Add support for multithreaded highlighting. Uses all available logical CPU cores by default and
   can be tweaked with the <code>numHighlightingThreads</code> and <code>maxQueuedPerThread</code> attributes on the
   <code>OcrHighlightComponent</code> in <code>solrconfig.xml</code>.
-- Removed <code>PageCacheWarmer</code>, no longer needed due to multithreading support.</p>
+- Removed <code>PageCacheWarmer</code>, no longer needed due to multithreading support.
+- Completely refactored, simplified and optimized I/O stack to reduce number of file system reads
+  and allocations/data copies during highlighting, accounting for a significant performance improvement
+  over previous versions (4-8 times faster in a synthetic benchmark that was not I/O-bound)
+- We no longer memory-map files for reading. Benchmarking revealed that it did not improve performance
+  with the new I/O stack (probably due to the reduced amount of actual reads), on the contrary,
+  performance was improved for many concurrent queries. A huge drawback of the memory-mapped approach
+  was that in the presence of I/O errors like disappearing mounts, truncated files, etc, the JVM could
+  simply crash (due to the kernel sending a <code>SIGBUS</code> signal when encountering an I/O error).</p>
 <h2 id="085-2024-04-25">0.8.5 (2024-04-25)</h2>
 <p><a href="https://github.com/dbmdz/solr-ocrhighlighting/releases/tag/0.8.5">GitHub Release</a></p>
 <p><strong>Changed:</strong>

wip/example/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/formats/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/index.html

@@ -14,7 +14,7 @@
 
 
       <link rel="icon" href="assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/indexing/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/installation/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 

wip/performance/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">
 
 
 
@@ -547,6 +547,18 @@ <h2 id="storage-layer">Storage Layer</h2>
 <p>Generally speaking, local storage is better than remote storage (like NFS or CIFS), due to the network latency, and
 flash-based storage is better than disk-based storage, due to the lower random read latency and the possibility to
 do parallel reads. A RAID1/10 setup is preferred over a RAID0/JBOD setup, due to the increased potential for parallel reads.</p>
+<p>When building passages during highlighting (i.e. determining where a snippet starts and ends), the plugin reads
+the OCR files in aligned sections and caches these to reduce the number of reads and allocations. The bigger
+the cache size, the more data is read from the disk, i.e. the chances of cache hits increase. However, this
+comes at the cost of more memory usage and more allocations in the JVM, which can have a performance impact.
+By default, the plugin uses a section size of 8KiB with a maximum number of cached sections of 10,
+which is a good trade-off for most setups and performed well in our benchmarks. If you want to tweak these
+settings, use the <code>sectionReadSizeKib</code> and <code>maxSectionCacheSizeKib</code> parameters on the <code>OcrHighlightComponent</code>
+in your <code>solrconfig.xml</code>:</p>
+<ul>
+<li><code>sectionReadSizeKib</code>: The size of the sections that are read from the OCR files. The default is 8KiB.</li>
+<li><code>maxSectionCacheSizeKib</code>: The maximum memory that is used for caching sections. The default is 10 * <code>sectionReadSizeKib</code>.</li>
+</ul>
 <h2 id="concurrency">Concurrency</h2>
 <p>The plugin can read multiple files in parallel and also process them concurrently. By default, it will
 use as many threads as there are available logical CPU cores on the machine, but this can be tweaked

wip/query/index.html

@@ -16,7 +16,7 @@
 
 
       <link rel="icon" href="../assets/images/favicon.png">
-      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.24">
+      <meta name="generator" content="mkdocs-1.6.0, mkdocs-material-9.5.25">