Runtime of program using a large amount of memory stalls

[ilanggear]

I’m working on code to collect unigram and bigram counts of words and word features. For now I’m just working with less than a dozen smallish documents. Below are the results of @time on the first few docs. After the last entry the performance stalls and never recovers. I’m sure I’m stretching the limits of my MacBook Pro laptop’s memory capacity, but that doesn’t seem to be the main issue from what I can tell. I’ve tried to run Profile and it shows a massive percentage of the time used in “@Base/task.jl:921; poptask(W::Base.InvasiveLinkedListSynchronized{Task})”.

But I’m not sure if I’m reading it properly, or how to address that. Any info would be much appreciated!

5.223379 seconds (9.21 M allocations: 635.708 MiB, 15.49% compilation time)
13.186192 seconds (24.95 M allocations: 1.644 GiB, 23.21% gc time)
13.717961 seconds (10.31 M allocations: 885.446 MiB, 40.14% gc time, 0.15% compilation time)
45.435480 seconds (16.32 M allocations: 751.255 MiB, 23.21% gc time)
65.192106 seconds (13.25 M allocations: 1.571 GiB, 54.54% gc time)
22.686218 seconds (11.96 M allocations: 544.884 MiB)
89.156276 seconds (11.41 M allocations: 519.487 MiB, 49.02% gc time)

[SteffenPL]

I think more information might be needed to help… Ideally, a minimal working example (but I understand that might be difficult in the setup.)

The default link for performance tips is here (which you might know already): Performance Tips · The Julia Language. For profiling, you could use Profiler · Julia in VS Code, which shows at least what the different threads are doing.

A large amount of time seems to be spent in GC, maybe there is some type-instability or some data which you could cache more effectively?

Another guess would be that some of the String operations are leading to the allocations. For example, if your code relies on a lot of occursin or other expensive operations, then this could explain the allocations.

[ilanggear]

Thanks for the pointer to the VSCode extension profiler. That was much easier to use. I’m still working on a minimal example, and so will perhaps post again later if I can get one. Thx!

[ilanggear]

Is there anything meaningful to glean from the flat areas in the following performance profile? When I hover the mouse over the three rows in the flat column it says:

task.jl, poptask:line 921
task.jl, wait: line 930
task.jl, task_done_hook: line 634

I’m running the profiler on an internal function, not the top-level function, does that matter?

My code is pushing up against memory limits and stalls out somewhere; I’m trying to figure out where.

[gdalle]

No, the flat areas are just your main thread being idle, you probably want to zoom in on the left hand part. If you use the VSCode profiler you can ctrl+click on any part of the flame graph and it will take you directly to the corresponding function