RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-06-01 03:08:13 +00:00
Code Issues Activity Actions

LibDSP: Optimize note processing

Browse source 
Previously, a collection of notes (Vector or Array) would be created and
promptly deleted for every sample (at least 44 thousand times per
second!). This was measured to be one of the most significant
performance drawbacks as well as the most obvious performance
improvement I could currently find here. Although it will not cause
Piano to lag currently (at least on virtualized systems), I see an
incoming issue once we get the capability to use more processors.

Now, we use a HashMap correlating pitches to notes, and Track reuses the
data structure in order to avoid reallocations. That is the reason for
introducing the fast clear_with_capacity to HashMap.
This commit is contained in:
kleines Filmröllchen 2021-09-28 17:54:48 +02:00 • committed by Andreas Kling
parent 557be4649d
commit c2340a1b1f
3 changed files with 33 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

9
Userland/Libraries/LibDSP/Music.h
View file

@ -6,6 +6,7 @@
#pragma once
#include <AK/HashMap.h>
#include <AK/Types.h>
#include <AK/Variant.h>
#include <AK/Vector.h>
@ -33,12 +34,14 @@ enum class SignalType : u8 {
Note
};
struct Signal : public Variant<Sample, Vector<RollNote>> {
using RollNotes = OrderedHashMap<u8, RollNote>;
struct Signal : public Variant<Sample, RollNotes> {
using Variant::Variant;
ALWAYS_INLINE SignalType type() const
{
return has<Sample>() ? SignalType::Sample : has<Vector<RollNote>>() ? SignalType::Note
: SignalType::Invalid;
return has<Sample>() ? SignalType::Sample : has<RollNotes>() ? SignalType::Note
: SignalType::Invalid;
}
};