Imported Upstream version 1.72.0

[platform/upstream/boost.git] / doc / html / poly_collection / performance.html

diff --git a/doc/html/poly_collection/performance.html b/doc/html/poly_collection/performance.html
index 1215671..344f47c 100644 (file)
--- a/doc/html/poly_collection/performance.html
+++ b/doc/html/poly_collection/performance.html
@@ -482,7 +482,7 @@
 <li class="listitem">
             Directly as initialized by the process described for the <a class="link" href="performance.html#poly_collection.performance.insertion_tests" title="Insertion tests">insertion
             tests</a>. The sequence of types is complex enough that CPU's branch
-            prediction mechanisms are not able to fully anticipate it <a href="#ftn.poly_collection.performance.processing_tests.f0" class="footnote" name="poly_collection.performance.processing_tests.f0"><sup class="footnote">[19]</sup></a>. As elements are ordered according to their construction
+            prediction mechanisms are not able to fully anticipate it <a href="#ftn.poly_collection.performance.processing_tests.f0" class="footnote" name="poly_collection.performance.processing_tests.f0"><sup class="footnote">[21]</sup></a>. As elements are ordered according to their construction
             time, certain degree of memory contiguity is expected.
           </li>
 <li class="listitem">
@@ -713,7 +713,7 @@
 </div>
 <div class="footnotes">
 <br><hr style="width:100; text-align:left;margin-left: 0">
-<div id="ftn.poly_collection.performance.processing_tests.f0" class="footnote"><p><a href="#poly_collection.performance.processing_tests.f0" class="para"><sup class="para">[19] </sup></a>
+<div id="ftn.poly_collection.performance.processing_tests.f0" class="footnote"><p><a href="#poly_collection.performance.processing_tests.f0" class="para"><sup class="para">[21] </sup></a>
               This has been verified empirically: simpler cycles did indeed yield
               better execution times.
             </p></div>