Since AST interpreter switches to bytecode to execute generator
functions, arguments stored in local variables always need to be
initialized for such functions.
`memcpy()` and `memmove()` are functionally equivalent if the source and
destination memory regions do not overlap. If this is the case, we
should prefer `memcpy()` as it's implemented in a simpler and faster
way. As our `memcpy()` starts copying from the lowest address first,
relaxing a `memmove()` call to `memcpy()` is safe if the destination:
- starts at a lower address than the source
- starts at a higher address than the source's end
Using local variables to store function parameters makes Kraken tests
run 7-10% faster.
For now this optimization is limited to only be applied if:
- Parameter does not use destructuring assignment
- None of the function params has default value
- There is no access to "arguments" variable inside function body
Converting a base value to an Object is performed by Reference::delete_.
Doing this early in the bytecode operator could be observable, although
it would likely be the first observable step in Reference::delete_
anyways. This will just align these operators with upcoming operators
for super references, where doing this coercion first will be observable
(we need to throw an exception for deleting a super property before this
coercion).
This implementation detail of audio support in ladybird is a QObject
that needs moc'd by the moc tools. Putting it in its own file follows
the pattern we have for all the other QObjects in Ladybird.
The main missing features are rootMargin, proper nested browsing
context support and content clip/clip-path support.
This makes images appear on some sites, such as YouTube and
howstuffworks.com.
These are not strictly unresolvable references. Treating them as such
fails an assertion in the `delete UnaryExpression` semantic (which is
Reference::delete_ in our implementation) - we enter the unresolvable,
branch, which then asserts that the [[Strict]] slot of the reference is
false.
We've peppered this workaround around the code base as needed in a few
different ways. This adds a helper class to perform this workaround in
order to simplify doing so, and ensure cleanup occurs in a RAII fashion.
This also makes it easier to grep for places where this workaround is
employed.
- Pre-allocate and reuse sample decompression buffers. In many FLAC
files, the amount of samples per frame is either constant or the
largest frame will be hit within the first couple of frames. Also,
during audio output, we need to move and combine the samples from the
decompression buffers into the final output buffers anyways. Avoiding
the reallocation of these large buffers provides an improvement from
16x to 18x decode speed on strongly compressed but otherwise usual
input.
- Leave a FIXME for a similar improvement that can be made in the
residual decoder.
- Pre-allocate audio chunks if frame size is known.
- Use reasonable inline capacities in several places where we know the
maximum or usual capacity needed.
This now searches the memory in blocks, which should be slightly more
efficient. However, it doesn't make much difference (e.g. ~1% in LZMA
compression) in most real-world applications, as the non-hint function
is more expensive by orders of magnitude.
This factors out a lot of complicated math into somewhat understandable
functions.
While at it, rename `next_read_span_with_seekback` to
`next_seekback_span` to keep the naming consistent and to avoid making
function names any longer.
The "operation modes" of this function have very different focuses, and
trying to combine both in a way where we share the most amount of code
probably results in the worst performance.
Instead, split up the function into "existing distances" and "no
existing distances" so that we can optimize either case separately.
We will be adding extra logic to the CircularBuffer to optimize
searching, but this would negatively impact the performance of
CircularBuffer users that don't need that functionality.
backward-cpp 1.6 wasn't compatible with the latest version of binutils
(which we are using). This is now fixed upstream, but it forces us to
build with the latest commit and not a published version.
Instead of using a seek tolerance value to get close enough to the
target, we can skip frames forward until we pass the target, then seek
back to the previous frame. That puts us in a position to immediately
decode the frame containing the target sample.
Previously, the FLAC loader would not skip samples to reach its seek
target if it saw that the current sample in the loader is closer to the
target than the seek point it finds. This prevents seeking forward when
there are no seek points past the current position.
Previously, the calculation of the distance to the previous seekpoint
would always behave as if a seek point existed at sample 0, meaning
that it would never place a seek point there. If we instead treat it as
the maximum distance if no sample is present, a seek point will be
placed.
