Inserting with multiple VALUES at a time is definitely a good idea. You may also want to switch to preparing the INSERT and reusing it multiple times. Both for inserting a single row many times and for batching multiple VALUES many times in one transaction. You may also want to take a look at COPY FROM or LOAD DATA LOCAL (if on MySQL).
In my project i am using sqlite due to the offline nature of the application. I am not really versed in prepared statements but i will have a look at the documentation.
The spread operator provides a convenient syntax to do custom object clone operations or array and arguments custom stuff, etc. it works particularly well for things that require short iterations. Dismissing it entirely because it breaks call stack limits when spreading a 100k array into arguments is not a good takeaway. These kind of strong positions tend to end up in code reviews and sometimes unfortunately end up blocking good usage of cool operators (such as spread) and ideomatic patterns. All-in and all-out positions tend to neglect the sweet spot of compromise where good things flow for a good majority of use cases. (And yet, taking a non-binary approach can also be seen as binary - are you considering all compromise scenarios or are you not? - the end point being that it might be best not to take things too seriously)
My main issue is it causing an allocation every time its used. Sometimes preallocating and replacing elements is better and more efficient - but of course i was exaggerating :)
I love the spread operator, but, unless you’re using an immutability library, immutability everywhere usually means spread operators everywhere. I have seen this lead to serious performance problems that can be thorny to fix and endemic in React applications. So I don’t think the author’s takeaway is too far off the mark. Like React’s authors, I too was once drunk on shoehorning functional programming principles into JavaScript. React applications seem to be suffering from a collective functional hangover as a result. Vue’s reactivity model does not necessitate the spread operator so much, nor does using the spread operator in Vue components tend to create the same degree of performance problems.
Inserting with multiple VALUES at a time is definitely a good idea. You may also want to switch to preparing the INSERT and reusing it multiple times. Both for inserting a single row many times and for batching multiple VALUES many times in one transaction. You may also want to take a look at COPY FROM or LOAD DATA LOCAL (if on MySQL).
I’ve done some basic ballparking for MySQL, Postgres and SQLite here: https://github.com/eatonphil/databases-intuition?tab=readme-ov-file#mariadb-load-data-local.
In my project i am using sqlite due to the offline nature of the application. I am not really versed in prepared statements but i will have a look at the documentation.
If you’re running offline, take a look at the
.importcommand for sqlite.https://sqlite.org/cli.html#importing_files_as_csv_or_other_formats
.importjust uses a single insert prepared statement in a transaction (source in latest release 3.45.2).The spread operator provides a convenient syntax to do custom object clone operations or array and arguments custom stuff, etc. it works particularly well for things that require short iterations. Dismissing it entirely because it breaks call stack limits when spreading a 100k array into arguments is not a good takeaway. These kind of strong positions tend to end up in code reviews and sometimes unfortunately end up blocking good usage of cool operators (such as spread) and ideomatic patterns. All-in and all-out positions tend to neglect the sweet spot of compromise where good things flow for a good majority of use cases. (And yet, taking a non-binary approach can also be seen as binary - are you considering all compromise scenarios or are you not? - the end point being that it might be best not to take things too seriously)
My main issue is it causing an allocation every time its used. Sometimes preallocating and replacing elements is better and more efficient - but of course i was exaggerating :)
I love the spread operator, but, unless you’re using an immutability library, immutability everywhere usually means spread operators everywhere. I have seen this lead to serious performance problems that can be thorny to fix and endemic in React applications. So I don’t think the author’s takeaway is too far off the mark. Like React’s authors, I too was once drunk on shoehorning functional programming principles into JavaScript. React applications seem to be suffering from a collective functional hangover as a result. Vue’s reactivity model does not necessitate the spread operator so much, nor does using the spread operator in Vue components tend to create the same degree of performance problems.
using a cursor instead of connection.run might be an spreed improvment