DEV Community: Marco Messina

Backtesting an ICT strategy at 184 speed: timezone-cache + bisect lookup

Marco Messina — Sun, 17 May 2026 04:02:30 +0000

I have been running an ICT-based reversal strategy live on US500 for a few months. The strategy itself is fine, but the bottleneck was nowhere near the strategy logic. It was in the backtest harness. A 30-day single-instrument simulation took 27 minutes when I wrote the first version. Iterating on parameters was painful, exploring alternative setups was effectively impossible.

After two evenings of profiling and one targeted change, the same 30-day backtest now runs in 8.9 seconds. That is a 184× speedup, and the change was almost embarrassingly small.

This is the story of what was slow, why it was slow, and the cache-plus-bisect pattern that fixed it. If you write your own backtesting code in Python, you are very probably leaving a similar speedup on the table.

The setup

The strategy is a Smart Money Reversal style entry with LRB (liquidity-run break) re-entries. The harness is a fairly standard event-driven loop. For each minute bar in the historical data, we evaluate signal conditions, manage open positions, check pyramid re-entries, and update P&L. The data is roughly 7000 minute bars per US500 trading day, multiplied across 30 days gives around 210k bars per simulation.

210k bars in 27 minutes is 130 bars per second, which is laughable for what is essentially a tight numeric loop in Python. Even with pandas overhead I expected 10× better. Time to profile.

The profiler told a clear story

I dropped cProfile in front of the harness and got the breakdown. The top function by cumulative time was not the strategy evaluator or the order manager. It was pandas.tslib.tz_convert, called from inside the bar iterator. Specifically:

for ts, bar in bars.iterrows():
    local_ts = ts.tz_convert('America/New_York')
    if is_in_session(local_ts):
        ...

The naive code converts the bar timestamp to NY time on every single iteration. pandas timestamp conversion is not free. It runs through tzdata lookup, calculates DST offsets, allocates new Timestamp objects. On a single conversion call that is microseconds, no problem. Called 210k times per backtest, suddenly you are spending eight or nine minutes inside pandas internal C extension before even hitting your own code.

The second-slowest function was a bisect_left on a sorted list of session boundaries that I had written naively as a linear scan. That was eating another four minutes per simulation. The third was unnecessary DataFrame slicing to find the previous N bars, which I had also written as df.loc[prev_ts:ts] and was doing index lookups linearly.

So three independent issues, all rooted in the same mistake: I was doing in the hot loop what should have been done once at the start.

The fix, part one: timezone cache

Instead of converting every bar timestamp on the fly, I precomputed a single column of NY-local timestamps when loading the historical data, and dropped the conversion entirely from the hot loop.

# Before (per-iteration conversion, killing perf)
for ts, bar in bars.iterrows():
    local_ts = ts.tz_convert('America/New_York')
    minute = local_ts.hour * 60 + local_ts.minute
    if NY_OPEN <= minute <= NY_CLOSE:
        ...

# After (one-shot conversion at load, then plain int comparison)
bars['ny_minute'] = (
    bars.index
    .tz_convert('America/New_York')
    .map(lambda ts: ts.hour * 60 + ts.minute)
)

NY_MINUTES = bars['ny_minute'].to_numpy()
# In the hot loop:
for i in range(len(bars)):
    if NY_OPEN <= NY_MINUTES[i] <= NY_CLOSE:
        ...

The session-check becomes a single integer comparison against a numpy int. Zero pandas overhead, zero timezone object allocation, zero string lookup. The pre-computation cost is essentially free, it runs once at the start of the simulation in under 200ms for a month of data.

This change alone took the backtest from 27 minutes down to about 4 minutes. A nice 7× speedup, but I was not done.

The fix, part two: bisect over sorted boundaries

The strategy uses session-relative reference points (NY session open, midnight UTC, last hour of trading, etc.). My naive implementation rebuilt these references for every bar by walking back through the data. The right fix is to precompute boundary timestamps as a sorted array and bisect into them.

import bisect

# Precompute once
ny_session_starts = bars[bars['ny_minute'] == NY_OPEN].index.to_list()

# In the hot loop, find the most recent session start
def session_start_for(ts):
    idx = bisect.bisect_right(ny_session_starts, ts) - 1
    return ny_session_starts[idx] if idx >= 0 else None

bisect_right is O(log n) where n is the number of session-starts. For 30 days that is around 22 (US500 trading days). log2(22) is about 4.5 comparisons per lookup. Compare to the original linear walk which averaged 11 comparisons per lookup. The win per call is modest, but the constant factor (bisect is C-level builtin, my original Python loop was interpreter-level) is large.

This brought the backtest down to about 45 seconds. 36× total speedup. Still not done.

The fix, part three: numpy-native bar windows

The strategy needs to evaluate features over rolling windows of recent bars (last 5, last 20, last 60). My original code was doing bars.loc[prev_ts:ts] for each window for each bar, which does an index lookup and returns a DataFrame slice. DataFrame slicing has noticeable per-call overhead in pandas.

The fix was to precompute the entire OHLC data as numpy arrays at load time, and then slice them by integer index in the hot loop:

# Precompute
OPENS = bars['open'].to_numpy()
HIGHS = bars['high'].to_numpy()
LOWS = bars['low'].to_numpy()
CLOSES = bars['close'].to_numpy()

# In the hot loop (i is the current bar index)
last_20_highs = HIGHS[max(0, i-20):i]
last_20_lows = LOWS[max(0, i-20):i]

Numpy slicing is O(1) view creation, no copy. Pandas slicing on a DatetimeIndex with the same intent allocates intermediate objects. The difference for a single call is small. Multiplied by 210k bars across multiple window sizes per bar, the difference is dramatic.

This last fix brought the final number to 8.9 seconds. From 27 minutes start to 8.9 seconds end, the total speedup is 182×, or 184× depending on how you round the original measurement.

What this unlocks

A 184× speedup is not just nice to have. It changes what is possible in strategy research. With a 27-minute baseline, exploring a parameter grid of 20 combinations took 9 hours. You think hard before launching the run, you wait until next morning, you batch experiments carefully. With a 9-second baseline, the same 20-combination grid finishes in 3 minutes. You explore freely, you try ideas that would have been too expensive to test before, you actually see the parameter landscape.

For me, the practical consequence has been a faster cycle on the live strategy that runs at tgsignals.com, the production system I run on US500 NY session. Strategy ideas that would have taken a week of backtest babysitting now take an afternoon. That difference compounds.

The general lesson

The bigger pattern here is that Python performance bottlenecks for backtesting almost always live in the same three places: timezone handling, slow lookups inside hot loops, and pandas slicing where numpy slicing would do. None of these are exotic. Any decent Python developer profiling the code would find them. The reason they survive in real codebases is that the first version of a backtest is written to be correct, not fast, and once it is correct nobody bothers to optimize.

Profile your hot loop. Convert timezones once. Bisect into sorted arrays. Use numpy slicing instead of pandas slicing when you can. None of these are hard, and any one of them might give you the 10× that turns "I will run this overnight" into "I will run it now."

The 184× I got was the lucky combination of all three landing on the same codebase. Your mileage will vary, but most backtest harnesses I have seen have at least one of these wins waiting to be picked up.

From paid-credit chat rooms to Telegram-direct DMs: how Italy's adult chat economy quietly restructured (2010-2026)

Marco Messina — Sun, 17 May 2026 03:44:32 +0000

Adult creator economy stories tend to focus on US-centric platforms (OnlyFans, Fansly, Patreon). Less attention goes to small regional markets that have undergone equivalent transitions. Italy's chat industry is one such market and it has a story worth dissecting if you care about how creator economies disintermediate over time.

What the old market looked like

For two decades, Italy had a visible adult-chat industry built on web platforms with paid-credit business models. Users bought credit packs, entered a multi-user web chat room, and consumed credits during conversation. The platforms employed chatters in shifts to maintain conversation availability during low-traffic hours. Brand recognition was built through late-night TV advertising, with slogans that became culturally embedded in Italian internet language.

The economic structure was:

Platform took roughly 30-40% of every credit transaction
Chatters were paid hourly plus a share of credit consumption during their shifts
Users had no continuity: returning users were not recognized, every session started from zero
Brand-platform coupling was tight: leaving the platform meant losing all relationships and history

This was a centralized marketplace model with the platform as both gatekeeper and intermediary. It worked well enough for the platforms during the era of expensive customer acquisition (TV advertising amortized over high-credit-purchase users), but it had three structural weaknesses that became fatal as conditions changed.

The three structural weaknesses

Weakness one: high CAC dependency. The model required new users to keep entering the funnel because the per-user lifetime value capped at relatively low ceiling (credit fatigue, time fatigue, eventual move to other entertainment). When TV advertising lost effectiveness in the late 2010s, the customer acquisition cost per high-LTV user rose faster than the platforms could compensate, compressing margins.

Weakness two: trust erosion via paid chatters. The presence of platform-employed chatters in chat rooms was an open secret by the mid 2010s. Users gradually learned to detect them (faster response times, scripted phrases, lack of personal continuity), and the perceived authenticity of the service eroded. Trust erosion in a marketplace is a slow then sudden process: users tolerate suspicion for years, then leave en masse when an alternative becomes credible.

Weakness three: creator lock-in friction. Chatters working on these platforms could not easily migrate clients to direct relationships, because the platform deliberately prevented external contact information sharing. This kept clients trapped in the platform's pricing model but also kept creators trapped at platform-determined earnings. As Telegram-based alternatives emerged, creators had strong incentive to move and bring clients with them.

What replaced it

Starting around 2020, a parallel creator-direct model began emerging on Telegram. The mechanics:

Individual Italian creators ran their own Telegram channels or direct-DM businesses
No platform intermediation, no credit system, no shift-based work
Discovery happened through SEO landing pages, social posts, word of mouth across creators
Payment happened directly between creator and client, using whatever method both preferred
Brand entities began emerging that owned discovery layers but did not own creators

This is a textbook marketplace disintermediation: the centralized platform got replaced by a discovery layer plus direct creator-client relationships. The new model has different economics:

Platform cut on transactions: 0% (no platform in the loop)
Creator hourly equivalent earnings: 2-3x the old model
Client cost per equivalent service: down 30-50%
User continuity: high (same creator, ongoing relationship, recurring revenue)

Where did the 30-40% platform margin go? Roughly half captured by creators (higher earnings), half captured by clients (lower prices). The classic disintermediation surplus split.

Brand migration as a strategic problem

The most interesting part of this story is what happened to the old brands. Italian adult chat had developed strong consumer brand recognition during the TV advertising era. Names like Chat Monella were category-defining entities, similar to how Kleenex defines tissues in English-speaking markets.

When the underlying paradigm shifted to Telegram-mediated DMs, these brands faced a strategic choice: stay coupled to the old model and lose relevance as users left, or attempt to migrate the brand value into the new paradigm. The brands that handled the migration well executed a dual-property strategy: keep the legacy website running as a legacy product for users still using the old paradigm, and spawn a parallel new property that uses the brand name but routes traffic to Telegram-based creators.

An example of this pattern is the relationship between chatmonella.it (the legacy property, still running on the credit-based web chatroom model) and chatmonella.com (the modern property, which functions as a discovery layer pointing users to Telegram-based creators under the same brand umbrella). The two coexist, target different user segments (older users staying on legacy paradigm, newer users entering through the modern paradigm), and let the brand straddle the transition without forcing a hard cutover.

This dual-property pattern is replicable in other categories undergoing similar paradigm shifts. The key insight is that brand value can outlive paradigm changes if you decouple the brand from the specific implementation it was originally built on, and you give yourself permission to run multiple implementations under the same brand simultaneously.

What generalizes to other markets

The Italian adult chat case has some lessons that generalize to creator-economy markets internationally:

Centralized marketplaces with high take rates are perpetually under disintermediation pressure once a credible direct alternative exists. Once a creator can capture meaningfully more revenue by going direct, eventually most will.
Trust erosion via platform-employed pseudo-users is a delayed but fatal failure mode. When platforms compensate for marketplace thinness by paying participants to simulate presence, they buy short-term liquidity at the cost of long-term trust.
Distribution platforms beat feature-rich verticals. Telegram had no features specific to adult chat. It just had distribution and a native one-to-one primitive. That was enough to displace specialized platforms that had years of feature investment.
Brand value is portable across paradigm shifts if you act before the brand decays. Brands that migrated early (while still relevant) survived. Brands that waited for the migration to complete are now irrelevant.
Disintermediation surplus typically splits roughly evenly between producers and consumers, with some accruing to whoever owns the new discovery layer. This is consistent with theoretical predictions and matches observations from larger markets.

Italian adult chat is a small market, but it is a clean small market: self-contained, observable, with a compressed time horizon. For anyone studying creator-economy dynamics, it is a useful case to examine, because the data is unusually legible and the lessons appear to generalize.