Avoid using shift in flush

[kesne]

We noticed that there was a large amount of memory being created as part of the flush method, which seems to be due to some array optimizations in old JS engines. This seems to be easily fixed by changing to a simple for loop instead of a while loop that modifies the array during iteration. This is the same pattern that is used for the render_callbacks.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR relates to an outstanding issue, so please reference it in your PR, or create an explanatory one for discussion. In many cases features are absent for a reason.
• This message body should clearly illustrate what problems it solves. If there are related issues, remember to reference them.
• Ideally, include a test that fails without this PR but passes with it. PRs will only be merged once they pass CI. (Remember to npm run lint!)

Tests

• Run the tests tests with npm test or yarn test)

[ThePrimeagen]

This is great, shift is extremely expensive even in modern engines. cc trentm/node-bunyan#279

But, I will have to say @kesne , this i += 1... makes me feel like I don't even know you.

[Conduitry]

The test failure looks like a legitimate one. This apparently causes an infinite loop with custom elements.

[kesne]

@Conduitry It appears that the failed tests are due to the internal flush() method getting called infinitely, as property updates will end up calling flush(). This worked previously because the array was mutated, so the nested flush() calls wouldn't break.

It seems like the easiest resolution is to only allow one copy of the flush() function running at a time. I tested this change it seems like all tests pass after implementing it. This also seems more ideal from a memory perspective, as it should minimize callstack depth.

[olivierchatry]

Just wondering, would it be better to do the same thing ( replace while with a for ) for :

		while (binding_callbacks.length) binding_callbacks.pop()();

Not sure how JS engine handle memory allocation for array, but in any case, seems better to have a for loop in there, and reset the size at the end like you did for this optims ?

Also, is dirty_components can change while executing the for loop ? If it is constant, than, if I remember correctly, using .length have a cost as well ( better store it in a const before the for loop ). Small optims probably, but a gain is a gain!

[kesne]

@olivierchatry I'm unsure about the while case, it doesn't seem like there's any cases where it's causing problematic amounts of memory.

As for dirty_components changing, it can change while being iterated, so it is not possible to hoist it to a constant. In general, engines cache these frequently-accessed properties so that the lookup is not expensive.

[olivierchatry]

Ho, sorry, I was not clear, I was not talking about memory directly, but more about CPU usage, I'm wondering if it is faster to do a for then a clear, than a while with a pop.

Thanks for the heads up, I think you are very correct, it's minor optimization anyway, and I'm not even sure it would change anything.

[olivierchatry]

Actually, seems pop is faster than length = 0, wild guess, pop does not deallocate memory, just the internal "index", while length = 0 actually deallocate ( but would have to check the code ).

Anyway sorry for the thread, I'm reading the inside of svelt to learn it, and this PR seemed cool. Thanks a lot !

[Conduitry]

I merged this PR earlier today - Are there other changes that people think should happen before the next release? I don't have strong opinions or much familiarity with the performance differences between the various ways of doing this.

[kesne]

I don’t think so. This should be fine to release as-is. This solves a specific de-opt case whereas the discussion here is more around further ways to optimize.

[Conduitry]

3.18.2 has been released with this change, thanks!

[olivierchatry]

Ha yes, I did not want to hijack the PR at all, very sorry. Was just curious about some performance related questions while reading svelte code / PR. Thanks a lot for the great work !

…

On Sun, Feb 9, 2020, 3:38 PM Conduitry ***@***.***> wrote: 3.18.2 has been released with this change, thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4356?email_source=notifications&email_token=AAJVOG6FRUNBXIWV2OME2ZLRCAIPRA5CNFSM4KPMRSYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELGODRA#issuecomment-583852484>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJVOG2X5HPW764W73HO2HDRCAIPRANCNFSM4KPMRSYA> .