dsherret / dsherret/ts-morph

findReferencesAsNodes() memory consumption

Open
#1,440 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
6.2k
Forks
238
Avg merge
2m
Merged PRs (30d)
1

Description

I am new to ts-morph. Sorry in advance in case I miss something. ;)

**Describe the bug**

It seems like the result of `findReferencesAsNodes` is held in memory without ever getting released. See the code below, the visitor calls `findReferencesAsNodes` and memory usage continually increases until the node process blows up. (from 500mg to 4gb in my case)

Version: latest (^19.0.0)

```ts
for (const sourceFile of project.getSourceFiles()) {
sourceFile.forEachDescendant((node) => {
if (Node.isReferenceFindable(node)) {
node.findReferencesAsNodes(); // do nothing with it
}
});
}
```

```
<--- Last few GCs --->

[21444:0000028CA2228C10] 880782 ms: Mark-sweep 3980.9 (4132.7) -> 3965.6 (4133.5) MB, 2953.9 / 0.0 ms (average mu = 0.171, current mu = 0.076) allocation failure; scavenge might
not succeed
[21444:0000028CA2228C10] 884030 ms: Mark-sweep 3981.8 (4133.5) -> 3966.5 (4134.2) MB, 2906.9 / 0.0 ms (average mu = 0.139, current mu = 0.105) allocation failure; scavenge might
not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF65437D51F node_api_throw_syntax_error+175743
2: 00007FF654302E66 v8::internal::wasm::WasmCode::safepoint_table_offset+59654
3: 00007FF654304B72 v8::internal::wasm::WasmCode::safepoint_table_offset+67090
4: 00007FF654DAAAB4 v8::Isolate::ReportExternalAllocationLimitReached+116
5: 00007FF654D95E12 v8::Isolate::Exit+674
6: 00007FF654C17C6C v8::internal::EmbedderStackStateScope::ExplicitScopeForTesting+124
7: 00007FF654C24F4D v8::internal::Heap::PublishPendingAllocations+1117
8: 00007FF654C21FD7 v8::internal::Heap::PageFlagsAreConsistent+3367
9: 00007FF654C14707 v8::internal::Heap::CollectGarbage+2039
10: 00007FF654C2B0C3 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath+2099
11: 00007FF654C2B96D v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath+93
12: 00007FF654C3B1A3 v8::internal::Factory::NewFillerObject+851
13: 00007FF65492C285 v8::internal::DateCache::Weekday+1349
14: 00007FF654E48051 v8::internal::SetupIsolateDelegate::SetupHeap+558193
15: 00007FF600BAB969
```

**Expected behavior**

Memory not exploding.

Anyway, love this project. Thanks ;D

Contributor guide

Open the contributing guide

Research direction

Start with the reproduction using Project source files, sourceFile.forEachDescendant(), Node.isReferenceFindable(), and findReferencesAsNodes(). Monitor Node.js heap usage while repeatedly running the snippet, then trace the reference-finding path to determine why results remain retained; done means the reproduction no longer grows until the process runs out of memory.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
devtools, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.