Stream: git-wasmtime

Topic: wasmtime / issue #6122 cranelift::codegen::Context::optim...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2023 at 00:38):

jameysharp commented on issue #6122:

I'm going to defer review of this to @cfallin, but I'm only throwing a very small PR at you, Chris :laughing:

I'd love to hear more about what you're doing with Cranelift's logging output and why these particular statistics are getting in your way!

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2023 at 00:43):

y0nil commented on issue #6122:

I'd love to hear more about what you're doing with Cranelift's logging output and why these particular statistics are getting in your way!

I'm using wasmtime for invoking user defined functions very frequently.
When I enable logging in my library (the wasmtime 'host') - i see these traces _very_ frequently (see timestamps in example below), and the cost of writing/storing them is something i'd like to avoid (mostly, as i don't have much use for them)

2023-03-29 22:41:01.502471500
2023-03-29 22:41:01.502629500
2023-03-29 22:41:01.502779500
2023-03-29 22:41:01.502900100
2023-03-29 22:41:01.503019900
2023-03-29 22:41:00.252096500
2023-03-29 22:41:00.257645400
2023-03-29 22:41:01.502052400
2023-03-29 22:41:01.502336600
2023-03-29 22:41:01.502793100
2023-03-29 22:41:00.176485800
2023-03-29 22:41:01.502060200
2023-03-29 22:41:01.502202900
2023-03-29 22:41:01.502479400
2023-03-29 22:41:01.503021500
2023-03-29 22:41:01.512174700
2023-03-29 22:41:01.512327100
2023-03-29 22:41:01.512488900
2023-03-29 22:41:01.512649000
2023-03-29 22:41:01.512801300
2023-03-29 22:41:01.512986100
2023-03-29 22:41:01.513118500
2023-03-29 22:41:01.513262400
2023-03-29 22:41:01.513390300
2023-03-29 22:41:01.513752800
2023-03-29 22:41:01.512539200
2023-03-29 22:41:01.512747400
2023-03-29 22:41:01.513134400
2023-03-29 22:41:01.513691900
2023-03-29 22:41:01.514139200
2023-03-29 22:41:01.502582800
2023-03-29 22:41:01.503118900
2023-03-29 22:41:01.503637300
2023-03-29 22:41:01.504327500
2023-03-29 22:41:01.504771300
2023-03-29 22:41:01.502893100
2023-03-29 22:41:01.504117000
2023-03-29 22:41:01.507330000
2023-03-29 22:41:01.507565100
2023-03-29 22:41:01.507637900
2023-03-29 22:41:00.255436100
2023-03-29 22:41:00.255623300
2023-03-29 22:41:00.256040000
2023-03-29 22:41:01.502160000
2023-03-29 22:41:01.502787300
2023-03-29 22:41:00.257401100
2023-03-29 22:41:01.502866000
2023-03-29 22:41:01.503176800
2023-03-29 22:41:01.503707100
2023-03-29 22:41:01.504557500
2023-03-29 22:41:01.514354500
2023-03-29 22:41:01.514516200
2023-03-29 22:41:01.514729600
2023-03-29 22:41:01.515097800
2023-03-29 22:41:01.515743200
2023-03-29 22:41:01.518301700
2023-03-29 22:41:01.519219500
2023-03-29 22:41:01.520627400
2023-03-29 22:41:01.521185500
2023-03-29 22:41:01.521414900
2023-03-29 22:41:01.515598600

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2023 at 00:44):

y0nil edited a comment on issue #6122:

I'd love to hear more about what you're doing with Cranelift's logging output and why these particular statistics are getting in your way!

I'm using wasmtime for invoking user defined functions (in wasm 'guest's) very frequently.
When I enable logging in my library (the wasmtime 'host') - I see these traces _very_ frequently (see timestamps in example below), and the cost of writing/storing them is something I'd like to avoid (mostly, as i don't have much use for them)

2023-03-29 22:41:01.502471500
2023-03-29 22:41:01.502629500
2023-03-29 22:41:01.502779500
2023-03-29 22:41:01.502900100
2023-03-29 22:41:01.503019900
2023-03-29 22:41:00.252096500
2023-03-29 22:41:00.257645400
2023-03-29 22:41:01.502052400
2023-03-29 22:41:01.502336600
2023-03-29 22:41:01.502793100
2023-03-29 22:41:00.176485800
2023-03-29 22:41:01.502060200
2023-03-29 22:41:01.502202900
2023-03-29 22:41:01.502479400
2023-03-29 22:41:01.503021500
2023-03-29 22:41:01.512174700
2023-03-29 22:41:01.512327100
2023-03-29 22:41:01.512488900
2023-03-29 22:41:01.512649000
2023-03-29 22:41:01.512801300
2023-03-29 22:41:01.512986100
2023-03-29 22:41:01.513118500
2023-03-29 22:41:01.513262400
2023-03-29 22:41:01.513390300
2023-03-29 22:41:01.513752800
2023-03-29 22:41:01.512539200
2023-03-29 22:41:01.512747400
2023-03-29 22:41:01.513134400
2023-03-29 22:41:01.513691900
2023-03-29 22:41:01.514139200
2023-03-29 22:41:01.502582800
2023-03-29 22:41:01.503118900
2023-03-29 22:41:01.503637300
2023-03-29 22:41:01.504327500
2023-03-29 22:41:01.504771300
2023-03-29 22:41:01.502893100
2023-03-29 22:41:01.504117000
2023-03-29 22:41:01.507330000
2023-03-29 22:41:01.507565100
2023-03-29 22:41:01.507637900
2023-03-29 22:41:00.255436100
2023-03-29 22:41:00.255623300
2023-03-29 22:41:00.256040000
2023-03-29 22:41:01.502160000
2023-03-29 22:41:01.502787300
2023-03-29 22:41:00.257401100
2023-03-29 22:41:01.502866000
2023-03-29 22:41:01.503176800
2023-03-29 22:41:01.503707100
2023-03-29 22:41:01.504557500
2023-03-29 22:41:01.514354500
2023-03-29 22:41:01.514516200
2023-03-29 22:41:01.514729600
2023-03-29 22:41:01.515097800
2023-03-29 22:41:01.515743200
2023-03-29 22:41:01.518301700
2023-03-29 22:41:01.519219500
2023-03-29 22:41:01.520627400
2023-03-29 22:41:01.521185500
2023-03-29 22:41:01.521414900
2023-03-29 22:41:01.515598600

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2023 at 00:45):

cfallin commented on issue #6122:

Yup, sorry about that! The INFO-level logging is probably an artifact of early development (wanting to see the toplevel stats but not the step-by-step tracing) that leaked into the final version; we in general shouldn't have much or any logging below DEBUG in the compiler internals. Indeed a quick grep shows that this was the only one.

Last updated: Nov 22 2024 at 16:03 UTC