Build 1 publisher2 min readPublished September 24, 2026 at 1:43 AM PDT

A cached strptime only wins when the same date shows up 2,740 times

A week of measurements on one Mac mini puts the lru_cache wrapper around strptime at 3x when dates repeat and slightly slower when they do not. A Polars 2.0 release candidate finishes the same report in 0.13 s.

The Engineer · Build desk

What happened

Every figure comes from one machine, a Mac mini M4 Pro running Python 3.14.6, with five runs per configuration and medians reported.
On a million rows carrying only 365 distinct dates, the lru_cache version of the report finished in 1.29 s as a whole process and 1.03 s inside the script.
The write-up puts the cache trick at about 3x and only when inputs repeat; on a million unique dates it ran 6 percent slower than doing nothing.
All three versions wrote output files byte-identical to the original script's, all 48 rows.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

decision Choosing between the wrapper and the rewrite depends on a repeat rate you can state for your own data, because the same four lines of code are a 3x on one input distribution and a small tax on another.
constraint The 25x is an in-script comparison, so a job that starts a fresh interpreter on a schedule collects the whole-process ratio instead, which is 9.9x on the repeated-date data.
cost The 0.13 s costs a dependency and a rebuild of the report around read_csv, str.to_datetime, group_by and sort, paid once by whoever maintains the script.
exposure Anyone adopting on these figures is adopting a pre-release, and the numbers have to be taken again when 2.0 final ships.

lru_cache hashes the argument tuple and checks a dict before it calls the function. On a hit, a stored datetime comes back and strptime never runs. On a miss you pay the hash, the lookup, the call and the store. Spread 365 distinct dates over a million rows and each string arrives about 2,740 times, so 99.96 percent of lookups hit ^[1]. With a million unique dates every lookup misses, and the wrapper costs 3.24 s inside the script against 3.06 s plain ^[7]^[6].

The 3x and the 25x come from different columns of the same table. Inside the script the cache is 3.0x; measured as whole processes, start to exit, it is 2.6x ^[2]. Polars against the cached version is 25.8x in-script and 9.9x as a process ^[3]. A script on an hourly schedule pays the process number, because it pays interpreter startup on every run. The release candidate's two in-script medians, 0.04 s and 0.03 s, differ by 0.01 s, the last digit the table reports ^[5]^[8].

Subtract the columns and the plain script spends 0.26 s outside its timed section; the Polars script spends 0.09 s ^[6]. The note does not explain why the process that imports Polars carries less startup than the one that does not.

For the rewrite's number to transfer, one format string has to cover the column. The parse is `pl.col("date").str.to_datetime("%Y-%m-%d %H:%M:%S")` ^[13]. Mixed formats or nulls in the same column take a different code path. The rest of the report also has to fall out of a group_by and a sort, and in this one it does ^[12].

Two medians for the plain script are now published against the same data: 3.71 s in last week's video and 3.36 s this week, 10 percent apart ^[2]^[3]^[5]. The penalty the cache imposes on unique inputs, 5.7 percent at the process level, is smaller than the gap between those two baselines ^[4].

The write-up draws its line by how often the script runs. "If the script is yours and small, the cache is the cheaper fix," it says. "If it runs every hour on real data, the rewrite pays for itself the first day." ^[14]

The same note re-ran its uv benchmark on version 0.12.11 and landed within 4 percent of 0.11.6 across the same eight packages, so that upgrade buys features and not speed ^[16]. The Polars figures come from 2.0.0-rc.1, and the post says to re-check when 2.0 final ships ^[15].

What to watch

Whether the 2.0 final release holds the rc.1 timings on the same 48-row report.
A re-run on Linux with a slower disk, since every figure here comes from one Mac mini M4 Pro.
A version of the test where the date column needs more than one format string.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
All benchmarks were run on a Mac mini M4 Pro with Python 3.14.6, five runs each, with medians reported.
ReportedSupportedView cited source
[2]
Last week's video found that a script parsing one million date strings spent most of its time in strptime, and that caching the parser took it from 3.71 s to 1.20 s.
ReportedSupportedView cited source
[3]
With 365 distinct dates over 1,000,000 rows, the plain report.py took 3.36 s as a whole process and 3.10 s inside the script.
ReportedSupportedView cited source
[4]
With 365 distinct dates over 1,000,000 rows, the version with an lru_cache-wrapped parse_date took 1.29 s as a whole process and 1.03 s inside the script.
ReportedSupportedView cited source
[5]
With 365 distinct dates over 1,000,000 rows, Polars 2.0.0-rc.1 took 0.13 s as a whole process and 0.04 s inside the script.
ReportedSupportedView cited source
[6]
With 1,000,000 distinct dates and no repeats, the plain report.py took 3.32 s as a whole process and 3.06 s inside the script.
ReportedSupportedView cited source
[7]
With 1,000,000 distinct dates and no repeats, the lru_cache version took 3.51 s as a whole process and 3.24 s inside the script.
ReportedSupportedView cited source
[8]
With 1,000,000 distinct dates and no repeats, Polars 2.0.0-rc.1 took 0.12 s as a whole process and 0.03 s inside the script.
ReportedSupportedView cited source
[9]
The output files from all versions are byte-identical to the original script's, all 48 rows.
ReportedSupportedView cited source
[10]
The write-up states the cache trick gave about 3x and only when inputs repeat; with unique inputs it was 6% slower than doing nothing.
ReportedSupportedView cited source
[11]
The write-up states Polars does not care whether inputs repeat: 25x faster than the cached version, with the whole process, interpreter startup included, finishing in 0.13 s.
ReportedSupportedView cited source
[12]
The cost of the Polars version is a dependency, and the code is not a two-line change: the report becomes a read_csv, a str.to_datetime, a group_by and a sort.
ReportedSupportedView cited source
[13]
The Polars version parses the column with pl.col("date").str.to_datetime("%Y-%m-%d %H:%M:%S").
ReportedSupportedView cited source
[14]
"If the script is yours and small, the cache is the cheaper fix. If it runs every hour on real data, the rewrite pays for itself the first day."
ReportedSupportedSource: the dev.to write-upView cited source
[15]
The Polars version tested is a release candidate (2.0.0-rc.1) and the post says to re-check when 2.0 final ships.
ReportedSupportedView cited source
[16]
On the same eight packages with caches off, uv 0.12.11 and uv 0.11.6 were within 4% of each other, with install 6.2x faster than pip 26.1.2 and the full flow 6.9x faster, so upgrading uv is about features, not speed.
ReportedSupportedView cited source
[d1]
365 distinct dates across 1,000,000 rows means each distinct string appears about 2,740 times, and 99.96 percent of cache lookups are hits.
DerivedSupported1 source— sign in to open
[d2]
The lru_cache speedup on repeated dates is 3.0x measured inside the script and 2.6x measured as a whole process.
DerivedSupported1 source— sign in to open
[d3]
Polars 2.0.0-rc.1 against the cached version on repeated dates is 25.8x inside the script and 9.9x as a whole process.
DerivedSupported1 source— sign in to open
[d4]
On unique inputs the cached version is 5.7 percent slower than the plain script as a whole process and 5.9 percent slower inside the script.
DerivedSupported1 source— sign in to open
[d5]
The two published medians for the plain script on the same data, 3.71 s and 3.36 s, are 10 percent apart.
DerivedSupported1 source— sign in to open
[d6]
Outside its timed section the plain script spends 0.26 s, and the Polars version spends 0.09 s.
DerivedSupported1 source— sign in to open

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 24, 2026
This week on one Mac mini: Polars 2.0 beats the cache trick 25 , uv 0.12.11 re-run, and what GPT-6 got right about our videos

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

The devlog on dev.to gives a builder the two numbers the decision turns on: 1.29 s when 365 dates repeat across a million rows, and 3.51 s against a plain 3.32 s when every date is unique. The Polars rewrite is printed in full, so the dependency and the four chained expressions are visible before anyone commits to them. The check worth copying is the dull one: all three versions emit byte-identical files, 48 rows, so the speedups buy the same output. Every figure comes from one Mac mini M4 Pro on Python 3.14.6, and no second machine or interpreter build is tested.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence70: 0100
Stated harness, one witness
Five runs, medians, the machine and Python version named, and the output files compared byte for byte against the original: the method is written down where a reader can argue with it. The limits are just as visible. One desktop, one interpreter build, and the same author who published last week's video, whose median for the uncached script was 3.71 s where this week's table says 3.36 s.
Adoption20: 0100
A candidate build and its one user
The record contains one user, the author. Polars 2.0 is a candidate published days before the post, and the uv item is an upgrade installed to re-run the blog's own earlier test. That shows the software exists and runs on a desktop, well short of a production report.
Hype gap+12: −100 understated0 aligned+100 overstated
Headline uses the in-script multiple
The 25x in the title is the in-script comparison. Counting interpreter startup, which is what an hourly job actually pays, Polars is 9.9x the cached version. Both columns are printed, so the stretch sits in the framing and not in the data, and the post is unusually careful elsewhere: it volunteers that the cache trick loses by 6% when nothing repeats.
Incentives30: 0100
An unpaid self-audit
The author is re-measuring their own earlier claim and the new numbers undercut it: last week's video promoted a cache wrapper, this week's table has a dependency swap beating it by a factor of ten on the same data. Nothing in the post is sold, and where one study it cites has a vendor relationship, Armature selling growth services to dev-tool vendors, the post says so.
Confidence60: 0100
Repeatable method, unreplicated result
I'd trust the direction of these numbers and not the third digit. The harness could be rebuilt in an afternoon, but the fastest figure comes from a release candidate the author himself says to re-check at 2.0 final, and no one has run the report on other hardware.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

A cached strptime only wins when the same date shows up 2,740 times

What happened

Why it matters

What to watch

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Sources

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources