Silence cats-effect starvation check

[yhefamly]

First of all, thank you for this really cool project ❤️

During my first tests, I noticed that cellar search --module mymodule MyClass prints cats-effect CPU starvation warnings (0.1.0-M4, on a MacBook Pro M4 and a larger sbt monorepo, search took ~10s total).

While a nuisance for human users, AI will process these warnings, wasting tokens on garbage. I briefly skimmed through the codebase and it seems blocking operations are properly handled (*), so this may just be due to the nature of cellar's work. cats-effect's IORuntimeConfig allows disabling the check via defaultCpuStarvationCheckInitialDelay = Duration.Inf, wdyt of doing so?

(*): It even seems you could remove some IO.blocking by using cats.effect.std.SystemProperties to read JVM props – the CE version does not block on reading, only when updating.

[rochala]

I had an attempted to make a proper fix for this by using IO.blocking in some places that caused this #17

It looks like I didn't get all of them. I'll try to repro it on some bigger sbt repository.
Disabling the starvation can also be made optional in config file maybe ? Ideally I would not disable it because some calls are not false positives and are actually something that should be IO.blocking

[rochala]

I've released new version. Let me know if it still happens

[yhefamly]

I checked and it still happens. Not while the build tool (sbt) is running, but once cellar has the data and crunches it. Which makes some sense, that's a large portion of CPU-bound work (loading class files seems to not be the bottleneck in my setup) without yields to the CE scheduler.

There are two things I believe to make sense:

1. Add an option to the new config to disable the starvation warnings. I'd propose it's on by default, but during development and CI, it should be switched off to show the warnings. Aka make them visible during development of cellar, but when using cellar (where it's just annoying).
2. Check whether during the hard work, we can reasonably yield back to the scheduler in between. Maybe it's even possible to split the work so that more than one CPU core can be utilised? I haven't checked the underlying libraries yet, but if something could be done there, that'd be huge.

[rochala]

I went for option 1, in the future we should consider adding tracing / logging and including starvation checks inside it.