Cost attribution
Circinus instruments Harmony patches and selected engine methods with a prefix and a postfix that read a stopwatch. Cost is attributed to the mod whose declaring assembly owns the patch method, which resolves reliably: on a 916-mod list, 1,723 of 1,723 patch costs were attributed with none unresolved.
Time is reported as share of measured frame time, never as raw milliseconds. Milliseconds are entangled with the hardware they were recorded on, so averaging them across machines produces a hardware census wearing a leaderboard's clothing.
Instrumentation is not free, so it is disclosed rather than hidden: our own patches are tagged and shown in the tables, and a run records whether profiling was active.
Tick rate and targets
Ticks per second is not one quantity. RimWorld's target rate is 60 x TickRateMultiplier, so it depends entirely on the speed the player chose:
| Normal | target 60 tps |
| Fast | target 180 tps |
| Superfast | target 360 tps |
| Ultrafast | target 900 tps |
A player achieving 200 tps at normal speed has hit the ceiling; one achieving 200 at ultrafast is at 22% of target and struggling. Comparing those two raw numbers is meaningless, so every comparison on this site uses percentage of target.
Ticks per second is the simulation; frames per second is rendering. They have different targets, different bottlenecks and different fixes. The simulation can stall while rendering stays perfectly smooth, and the reverse. They are never combined into one figure.
The hardware index
The index is a measured score, not a specification lookup. Circinus runs a frozen single-threaded benchmark and reports:
The workload mixes dependent integer and floating point arithmetic with an unpredictable branch, so it cannot be vectorised or optimised away, and it is deliberately similar in character to pathfinding and tick maths. An index that ranked machines differently from how RimWorld ranks them would be worse than no index.
Best of five, not the average
Every source of interference is one-directional: thermal throttling, background load and laptop power profiles can only ever make a pass slower. The fastest of five passes is therefore the least contaminated estimate, and averaging just folds in whatever noise happened to be present.
Frozen by contract
Changing the workload changes every score, so the benchmark carries a version. Scores from different versions are refused rather than silently mixed. Version 1 reported an arbitrary 100000/ms; version 2 reports the iteration rate above, and no v1 score is comparable to a v2 one.
Because it is measured rather than looked up, two machines with the same processor and different cooling, memory or power settings will score differently. That is the point.
How cohorts are formed
A cohort is the set of runs that are actually comparable to yours. Three axes:
- Hardware index, within +/- 60 of yours
- Mod count band, because share of frame shrinks as more mods compete
- Game speed, because the target differs and a target is not optional context
Bucketing on processor and graphics model strings instead would produce thousands of cohorts of two runs each, and the minimum-sample floor would then make nothing publishable at all. A measured index collapses that into a usable number of groups and needs no lookup table to curate.
On the cohort page, the mod count describes the run being compared. Raising it says that run had more mods loaded and still reached the same tick rate, which compares more favourably. It does not model adding mods to your game, which would lower the result rather than raise the ranking.
Percentiles
Placement is reported as a percentile of the cohort, not as a distance from the median. "27% above the median" reads naturally as "above 27% of machines", which is a different and much stronger claim; a percentile says exactly one thing.
The distribution is modelled as normal around the cohort median. Once enough real runs exist this will be replaced by the empirical distribution, which needs no assumption about shape.
Correlations
The predictors panel reports Pearson correlation between each hardware attribute and the achieved percentage of target, across the cohort. RimWorld's simulation is overwhelmingly single-thread CPU bound, which is why the CPU index correlates strongly and the graphics card essentially not at all.
Players routinely blame the graphics card for a low tick rate and buy the wrong upgrade. Capturing all three attributes lets the site demonstrate the relationship rather than claim it, which costs nothing extra once the data is collected.
When we refuse
A tool that answers everything confidently is a tool that is sometimes confidently wrong. Circinus declines in these cases by design:
| Fewer than 25 runs | no ranking, no verdict, figures shown but not placed |
| Profiling mismatch | an observed run is not comparable to an unobserved one |
| Different iteration counts | a different iteration count is a different experiment |
| Different calibration versions | scores are not on the same scale |
| Incomplete runs | kept and labelled, never silently averaged in |
A missing profiler reads as no data, never as zero cost. Otherwise an absent measurement would look like a performance win.
Induced cost, which we cannot attribute
Cost is time spent inside a mod's own code. If mod A spawns four hundred extra things and mod B's tick becomes more expensive as a result, that time is recorded against B, and B looks guilty.
Separating the two requires a controlled comparison on one machine with and without mod A, which is the run diff feature in the tool itself. The site cannot do it and does not claim to. Every figure here means "time spent in this mod's code" and never "time this mod caused".
Measured versus projected
Hardware indices are labelled in the interface:
- Measured - a real calibration score submitted from that processor
- Projected - scaled from published single-thread ratios, anchored on a measured part
Projected entries are estimates and are marked as such wherever they appear. They will be replaced by observed medians as runs arrive, not by better guesses. An uncorrected projection is indistinguishable from a measurement to anybody reading the site, which is why the label is carried all the way through.
The tier names are provisional in the same way. They should be percentiles of the observed corpus rather than fixed thresholds, and will be once a corpus exists.
What gets sent
Submission is opt-in and off by default.
- Coarsened hardware: processor model with vendor noise stripped, memory rounded to a tier, graphics model, operating system family with the build number removed
- A mod list hash, not an ordered manifest: a full list is close to a fingerprint
- Per-mod and per-patch costs, and the sample series
- An install id that is salted and hashed server side, used to rate-limit and de-duplicate rather than to identify
File paths are scrubbed before anything leaves the machine, which is covered by tests. No account, no email, nothing personal. Export and delete by install id.
API
Everything the site shows is served by a versioned REST API using the same types the in-game mod writes, so the client and the server cannot drift apart in how a run document is read.