|
| ▲ | Veserv 37 minutes ago | parent | next [-] |
| That just sounds like bad tracing implementations. A good tracing implementation should be able to drive gigabytes per second of trace logs to memory. If you are generating it slow enough to allow actual offload then you should be in the 1—10% range even if you are saturating your offload. You should, of course, upper bound this overhead by switching to a full time travel debugging solution, thus tracing everything, when you get to the 10-30% range. The only way you get to “majority” is if your trace implementation is slower than time travel debugging and provides less information, but then why choose something worse in every dimension. |
|
| ▲ | foota 15 minutes ago | parent | prev | next [-] |
| Just curious, why? Is this true even if you did something like a per-CPU histogram that uses atomic ops to increment? |
|
| ▲ | nicoburns an hour ago | parent | prev | next [-] |
| One legitimately great thing about LLMs is that it makes it feasible to add these kind of tracing instrumentations temporarily for profiling and then throw them away so they never reach source control let alone production. |
| |
| ▲ | jeffbee an hour ago | parent [-] | | I can get an LLM to trace my incomprehensible Tokio application which was also written by an LLM, which is why I don't understand its behavior. Truly the future we were promised. |
|
|
| ▲ | MomsAVoxell 2 hours ago | parent | prev [-] |
| If you’re not using eBPF to trace your app you’re doing it wrong. |
| |
