# Profiling code with heavy IO times

**URL:** <https://discourse.julialang.org/t/profiling-code-with-heavy-io-times/111589>\
**Category:** General Usage\
**Tags:** profiling\
**Created:** [March 13, 2024, 7:57pm UTC](https://discourse.julialang.org/t/profiling-code-with-heavy-io-times/111589 "2024-03-13T19:57:46Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ianfiske](https://avatars.discourse-cdn.com/v4/letter/i/58f4c7/32.png) [@ianfiske](https://discourse.julialang.org/u/ianfiske)\
**Post date:** [March 13, 2024, 7:57pm UTC](https://discourse.julialang.org/t/profiling-code-with-heavy-io-times/111589/1 "2024-03-13T19:57:46Z")

</div>

Usually I can get a lot of mileage out of the user-friendly `@profview` macro and I get all the info I need to spot performance bottlenecks. However, sometimes I have code where there is a lot of IO (e.g., downloading various data over the internet). In these cases, I have noticed that `@profview` (and I’m assuming the underlying machinery in `Profile`, seems to not capture the time spent in IO. It presents me with flamegraphs that look something like

 ![image](https://global.discourse-cdn.com/julialang/original/3X/e/e/eea2f2b313dedf8f7b0eb5f74081bc7018fb8717.png)

I don’t have an MWE I can share, but I’m wondering if anyone else has run into this and has an alternative mechanism for profiling IO-heavy code.

So far, I made some progress from the excellent TimerOutputs.jl package, but it’s a pretty manual process to add all of the various `@timeit` macros throughout a large package.