I'm pretty sure JS strings are pooled so only the pointers to the actual c strings are compared. (V8 for sure pools constant strings you declare with "...") That is a reason you can't just set some nth character in the string, like in C.
this is great, really love the quality of the video. my only comment would be to be judicious when trying to optimize, for example many of the tricks here you can find in the typescript compiler (shallow objects to make the property access path short, using ints instead of strings for enums, fixed shapes for the objects, etc) but thats because they are trying to squeeze every oz of performance out this shitty language, in everyday app design and work architecture matters a lot more, like avoiding doing unnecessary work and using the right data structures. but this shitty language can do a lot right off the bat, i abuse string.join everyday all day.
I was waiting for this video , thank you a lot I am learning C# , i see some new concepts like domain entity , value objects and this stuff , can you explain hiw to do it in node ?
"Premature optimization is the root of all evil" - Donald Knuth. Why would you bother rewriting arguably more readable code (e.g., the array method example)? First of all, an improvement of, say, 38% in most use cases is quite pointless unless you are having a hard constraint such as 16ms FPS rendering budget. Second, the performance gain, if there even remains one, may be gone with the next version of JS engines. In short, stick to the more readable and more maintainable code and only optimize if there is an actual reason to do so.
Speed optimization advices here are ok, but code style is very bad and inconsistent. You should have cleaned it up a bit instead of directly copying the article
This is ok for a general knowledge, but this is (and should be) useless in programming. Yes, due to how things have been build, there is a difference of performance of objects "not having the same shape" but nobody (or there is a code problem) will do some 1 million iterations on an array or objects. So build readable and concise code instead of some esoteric performance optimisation.
I'm pretty sure JS strings are pooled so only the pointers to the actual c strings are compared. (V8 for sure pools constant strings you declare with "...")
That is a reason you can't just set some nth character in the string, like in C.
Good point
Good examples. Also keeping the folder view open actually helps understanding what currently explained. 👌
man this exactly what i needed. could you spoil us further and make us video about user auth on enterprise level that would be sick
Happy to hear, mate! I'll put that on my list 😉
This one sounds really good
Thank you, can you please drop the links to the jsbenchmarks ?
Unfortunately they are not persisted, but you can find the approx. results in the original article linked in the description
this is great, really love the quality of the video. my only comment would be to be judicious when trying to optimize, for example many of the tricks here you can find in the typescript compiler (shallow objects to make the property access path short, using ints instead of strings for enums, fixed shapes for the objects, etc) but thats because they are trying to squeeze every oz of performance out this shitty language,
in everyday app design and work architecture matters a lot more, like avoiding doing unnecessary work and using the right data structures.
but this shitty language can do a lot right off the bat, i abuse string.join everyday all day.
I was waiting for this video , thank you a lot
I am learning C# , i see some new concepts like domain entity , value objects and this stuff , can you explain hiw to do it in node ?
Will check if there are such alternatives in Node!
Magnificent !!
"Premature optimization is the root of all evil" - Donald Knuth. Why would you bother rewriting arguably more readable code (e.g., the array method example)? First of all, an improvement of, say, 38% in most use cases is quite pointless unless you are having a hard constraint such as 16ms FPS rendering budget. Second, the performance gain, if there even remains one, may be gone with the next version of JS engines. In short, stick to the more readable and more maintainable code and only optimize if there is an actual reason to do so.
Great
Speed optimization advices here are ok, but code style is very bad and inconsistent. You should have cleaned it up a bit instead of directly copying the article
t-10 ;)
This is ok for a general knowledge, but this is (and should be) useless in programming. Yes, due to how things have been build, there is a difference of performance of objects "not having the same shape" but nobody (or there is a code problem) will do some 1 million iterations on an array or objects. So build readable and concise code instead of some esoteric performance optimisation.
Great