Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add tracing instrumentation for basic things #131

Merged
merged 2 commits into from
Jun 28, 2022

Conversation

Ekleog
Copy link

@Ekleog Ekleog commented Jun 1, 2022

Fixes #118

@Ekleog Ekleog marked this pull request as draft June 1, 2022 16:02
Comment on lines 174 to 179
allocated_functions,
jt_offsets,
function_relocations,
allocated_sections,
section_relocations,
trampolines
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason you didn't use skip_all here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I think I originally wanted to keep some info, and eventually gave up and skipped everything — that said the PR is not ready for in-depth review yet, sorry for having forgotten to open it as draft, I just published to get feedback about whether other people think tracing should be an optional or mandatory dependency 😅

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. My feeling is that there are very little we can hope to include as a field in spans today, so to me it makes most sense if we approach it from the direction of adding a field when we realize a need for it, rather than the other way around.

Introducing significant perf issues by accidentally debug-outputting parts of a 4MiB module structure seems like it'd be much worse than just missing that information, especially given that in production the contract can always be copied out from the database and investigated locally anyway.

@Ekleog
Copy link
Author

Ekleog commented Jun 24, 2022

I've just updated this PR.

@nagisa Can you review? Also, do you think this is enough to solve #118?

@Ekleog Ekleog marked this pull request as ready for review June 24, 2022 17:19
Copy link
Collaborator

@nagisa nagisa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think this is a reasonable first pass and enough to mark the issue as solved. If we end up finding ourselves wanting more instrumentation in the future, those cases should be handled on a case-by-case basis.

See the inline comment about the ThreadPoolBuilder::build(). r=me once resolved.

})
.collect::<Result<Vec<CompiledFunction>, CompileError>>()?
.into_iter()
.into_iter() // TODO: why not just collect to PrimaryMap directly?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC there are some special requirements for ParallelIterator. I tried fixing this mess once, and gave up quickly ^^

IMO we should just make rayon an unconditional dependency soon.

lib/compiler-singlepass/src/compiler.rs Outdated Show resolved Hide resolved
lib/compiler-singlepass/src/compiler.rs Outdated Show resolved Hide resolved
…ce showing huge time in the first rayon usage
@Ekleog Ekleog merged commit 4be4ad0 into near:near-main Jun 28, 2022
@Ekleog Ekleog deleted the tracy branch June 28, 2022 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Instrument the codebase more
2 participants