You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Basically, circles have auto_inc in their tables definitions, but ia_loop does not.
The consequence is that circles take a lot of time because the init_game_circles get called by each iteration of the benches, resulting in a big table with up to 1_000_000 rows when the setup was meant to be at most 10_000.
Then for the ia_loop the lack of auto_inc causes a unique constraint violation because the table is forbidden to grow.
Now:
In both, the database is initialized just once with the maximum amount of rows
Is removed group.measurement_time(Duration::from_secs(60 * 2)); that causes the bench to run longer than must
Removed the filtering in the ia_loop game loop based on timestamps, it causes the code to run differently between the integration test and benches.
Increase the size of ia_loop from [10, 100] to [500, 5_000] so criterion has something to measure:
# BEFORE
special/db_game/ia_loop/load=100
time: [0.0000 ps 0.0000 ps 0.0000 ps]
# AFTER
special/db_game/ia_loop/load=500
time: [386.62 ps 461.53 ps 640.54 ps]
API and ABI breaking changes
Nothing, but this change invalidates the numbers of previous benchmarks.
Expected complexity level and risk
1
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!
These benchmarks were run using callgrind,
an instruction-level profiler. They allow comparisons between sqlite (sqlite), SpacetimeDB running through a module (stdb_module), and the underlying SpacetimeDB data storage engine (stdb_raw). Callgrind emulates a CPU to collect the below estimates.
Measurement changes larger than five percent are in bold.
bugfixFixes something that was expected to work differentlyrelease-1.0release-anyTo be landed in any release window
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Corrections to how are benched
ia_loop
&circles
.Basically,
circles
haveauto_inc
in their tables definitions, butia_loop
does not.The consequence is that
circles
take a lot of time because theinit_game_circles
get called by each iteration of the benches, resulting in a big table with up to1_000_000
rows when the setup was meant to be at most10_000
.Then for the
ia_loop
the lack ofauto_inc
causes aunique constraint violation
because the table is forbidden to grow.Now:
group.measurement_time(Duration::from_secs(60 * 2));
that causes the bench to run longer than mustia_loop
game loop based ontimestamps
, it causes the code to run differently between the integration test and benches.ia_loop
from[10, 100]
to[500, 5_000]
so criterion has something to measure:API and ABI breaking changes
Nothing, but this change invalidates the numbers of previous benchmarks.
Expected complexity level and risk
1
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!