<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Algorithms on Brian Faust</title><link>https://wimdy.works/tags/algorithms/</link><description>Recent content in Algorithms on Brian Faust</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 01 Jan 0001 00:00:00 +0000</lastBuildDate><atom:link href="https://wimdy.works/tags/algorithms/rss.xml" rel="self" type="application/rss+xml"/><item><title>Index Tariffs Without Losing Charges</title><link>https://wimdy.works/thoughts/stop-scanning-every-tariff-row-for-every-service/</link><pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate><guid>https://wimdy.works/thoughts/stop-scanning-every-tariff-row-for-every-service/</guid><description>&lt;p&gt;Scanning ten thousand tariff rows for each of a hundred candidate services
means a million candidate-row visits before doing much interesting pricing.
Most visits may end with the same answer: this row belongs to another service.
Putting that loop behind a cache doesn&amp;rsquo;t remove it.&lt;/p&gt;
&lt;p&gt;I changed this part of my private logistics engine by preparing an in-memory
index of rows by carrier and service match. This wasn&amp;rsquo;t a database index.
The quote already had a restored runtime projection; the repeated work was
inside that projection. The index moved some predicates out of the per-candidate
loop, which made their preservation a correctness requirement rather than
merely a performance detail.&lt;/p&gt;</description></item></channel></rss>