MethodError from generic-function dispatch: deciding what to measure before optimizing a Julia hot path

MethodError in generic-function dispatch

Julia's dispatch machinery raises MethodError when no method of a generic function matches the supplied argument types, and the error names the function and the offending types. That failure mode is well documented, but it raises a measurement question for the surrounding code: a function can dispatch without any error and still be slow, because type instability and dynamic dispatch never surface as exceptions.

Goal and constraints

The goal is to decide, before changing any code, which measurement signal to trust when optimizing a hot loop in Julia (assuming a current 1.x release). The documented workflow suggests @time for a first look, a warm-up call to exclude JIT compilation latency, BenchmarkTools.@btime for repeatable timings, @profile for line attribution, and @code_warntype to expose non-concrete types.

The unresolved case: @btime reports high allocation counts, yet @code_warntype shows no non-concrete types in the suspect method, and the sampling profiler may misattribute time in short or heavily inlined functions.

Questions

1. When allocations are high but @code_warntype is clean, how should one distinguish allocation pressure from GC time from algorithmic complexity using documented tooling?
2. Is there a reliable way to confirm that profiler samples are not being misattributed due to inlining in very short functions?
3. Does the answer change across Julia versions, given that profiler and @code_warntype output formatting is not stable API?