Alex Gleason (npub1q3s…d26p) ditto.pub seems to have an infinite loop bug in `useAuthors`. I noticed because my CPU fan was spinning up when nothing much else was running. I profiled it and asked my clanker to figure it out:
==================
**Ditto appears to have a continuous React → database → React feedback loop in its `useAuthors` hook.** That’s the main repeated work in this profile.
Across the **9.38-second capture**:
| Work | Measured activity |
|---|---:|
| Ditto’s main page thread | **8.10 seconds of CPU — 86% of one core** |
| Timer callbacks traced to `useAuthors` cache updates | **2,461 — about 262/second** |
| Time inside those callbacks, including resulting work | **6.61 seconds** |
| IndexedDB `success` events | **2,461** |
The load stays high throughout the capture, so this isn’t just a brief startup spike.
I fetched the exact JavaScript bundle named in your profile. The [deployed `useAuthors` code](https://ditto.pub/assets/useAuthors-jBNN03G9.js) does this:
1. Each render creates a **fresh array** of sorted, unique author IDs.
2. That array is in a `useEffect` dependency list. Its identity changes every render, even when the authors haven’t changed.
3. The effect queries IndexedDB for those authors’ profiles.
4. It writes a **new `Map`** into the `["authors", …]` query cache, even when the profiles are unchanged.
5. The cache update causes another render, restarting the cycle.
The profile directly connects those cache writes to the query library’s zero-delay timer scheduler, followed by substantial React rendering work. Its roughly matching timer and database event counts strongly support this diagnosis. The hook’s five-minute `staleTime` doesn’t prevent this: the repeated reads happen in a separate effect.
**The developer fix:** make that effect depend on the *contents* of the author list rather than a newly allocated array, and preserve the existing cached `Map` when nothing changed. Both would break the unnecessary update cycle.
8020
npub1sg…q7wnj
2026-09-25 01:21:21 UTC
Author Public Key
npub1sgx8tkmn2gm4s788tssy5kgx0qjw9q8efda7wmg4afuyx2smdcjq2q7wnjSeen on
wss://nostr.landPublished at
2026-09-25 01:21:21 UTCEvent JSON
{
"id": "d0e3d74d12383e9e0a1f4469d01a7e14a0fe1bf7abb4be083165f66ed0eda55c",
"pubkey": "820c75db7352375878e75c204a59067824e280f94b7be76d15ea78432a1b6e24",
"created_at": 1790299281,
"kind": 1,
"tags": [
[
"p",
"0461fcbecc4c3374439932d6b8f11269ccdb7cc973ad7a50ae362db135a474dd"
],
[
"client",
"Ditto",
"31990:781a1527055f74c1f70230f10384609b34548f8ab6a0a6caa74025827f9fdae5:ditto"
]
],
"content": "nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p ditto.pub seems to have an infinite loop bug in `useAuthors`. I noticed because my CPU fan was spinning up when nothing much else was running. I profiled it and asked my clanker to figure it out:\n\n==================\n\n**Ditto appears to have a continuous React → database → React feedback loop in its `useAuthors` hook.** That’s the main repeated work in this profile.\n\nAcross the **9.38-second capture**:\n\n| Work | Measured activity |\n|---|---:|\n| Ditto’s main page thread | **8.10 seconds of CPU — 86% of one core** |\n| Timer callbacks traced to `useAuthors` cache updates | **2,461 — about 262/second** |\n| Time inside those callbacks, including resulting work | **6.61 seconds** |\n| IndexedDB `success` events | **2,461** |\n\nThe load stays high throughout the capture, so this isn’t just a brief startup spike.\n\nI fetched the exact JavaScript bundle named in your profile. The [deployed `useAuthors` code](https://ditto.pub/assets/useAuthors-jBNN03G9.js) does this:\n\n1. Each render creates a **fresh array** of sorted, unique author IDs.\n2. That array is in a `useEffect` dependency list. Its identity changes every render, even when the authors haven’t changed.\n3. The effect queries IndexedDB for those authors’ profiles.\n4. It writes a **new `Map`** into the `[\"authors\", …]` query cache, even when the profiles are unchanged.\n5. The cache update causes another render, restarting the cycle.\n\nThe profile directly connects those cache writes to the query library’s zero-delay timer scheduler, followed by substantial React rendering work. Its roughly matching timer and database event counts strongly support this diagnosis. The hook’s five-minute `staleTime` doesn’t prevent this: the repeated reads happen in a separate effect.\n\n**The developer fix:** make that effect depend on the *contents* of the author list rather than a newly allocated array, and preserve the existing cached `Map` when nothing changed. Both would break the unnecessary update cycle.",
"sig": "570560654697f231226015621cc2fa0fa88e5abee8050b51fa19adcadd62b335a4f65d6636d218e19888327d05a85b8b8c6c1a95ac1056d9ed3f046cbe9115be"
}