-
Notifications
You must be signed in to change notification settings - Fork 109
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
C# module benchmarks #1679
C# module benchmarks #1679
Conversation
Example run in Rust
vs C#
|
For the sake of posterity, here's EXPERIMENTAL_WASM_AOT vs regular C#:
only 2x slower than Rust (which is in line with my early microbenchmarks). |
This is great to have! |
public static ulong MomentMilliseconds() | ||
{ | ||
// Idk why Rust uses complicated math, but it seems like it should always return 1. | ||
return 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was purely to copy the way was done and use the time methods, but is likely that this could be just a const
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Since #1679, a call to the publish endpoint that doesn't update but create a database would drop errors and falsely return a success response. While the `ControlStateWriteAccess::publish` method can't currently express the different error branches, we make it so creation errors are returned as `Some(UpdateDatabaseResult::ErrorExecutingMigration)`.
Description of Changes
These are ported from Rust benchmarks 1:1 (similarly to how
sdk-test-cs
is ported fromsdk-test
) by using Copilot + elbow grease for manual fixes.When you set an environment variable
STDB_BENCH_CS=1
, this allows to run all the same module benchmarks as Rust currently does, except against an analogous C# implementation.API and ABI breaking changes
If this is an API or ABI breaking change, please apply the
corresponding GitHub label.
Expected complexity level and risk
How complicated do you think these changes are? Grade on a scale from 1 to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex change.
This complexity rating applies not only to the complexity apparent in the diff,
but also to its interactions with existing and future code.
If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning ways.
Testing
Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!