Of course it would be welcome. Though I think that's not necessarily where the low-hanging fruit lies. I think a) making sure that developers can work with more dense memory layouts b) making sure that developers have good raw SIMD APIs is probably way more important.
Dart VM does not do any vectorization - so the best way to ensure it happens is to do it by hand :)
Other than that it is on the case by case basis and requires looking at generating code before and after.
(Also our compilers are focused on code size so we avoid any optimizationa that expand code size)
Currently we never unroll loops in any of our compilers.
These days unrolling is usually only beneficial if it enables other optimizations across loop iterations because increase in code size can have worse impact than benefit from removing a well predicted branch.
throw is an expression returning Never, so that you could write
a ? throw B : c;
among other things
(I want to stress it here that function* here is not the same as a single function of Dart language - it is function + all inlined stuff, e.g. if you write something like `Vector(1,2).add(Vector(2, 3)`) compiler can still eliminate `Vector(1,2)` and `Vector(2,3)` if `add` is inlined).
I think bsky.app/profile/mral... answers it. It has to be created and used and not escape confines of a function*
Speaking of collections: "some" should have probably been "any". What I was trying to say is that if you do something like
var v = Vector();
var l = [];
list.add(v);
for (var u in l) { print(u.x); }
Even though v does not really escape confines of the function it can't "explode" into fields.
There is no documentation but you can read articles like en.wikipedia.org/wiki/Escape_... and chrisseaton.com/truffleruby/... to get the idea of the theory behind it.
It occurs if compiler can figure out that it can do it. Compiler can do it if some object is fully confined to the function* the way compiler sees it - this is not the same as Dart function, it is function plus all functions inlined into it.
But it is hard to answer this question in an abstract case. It would be easier if you gave a bit more details on what you are trying to optimize
In general if you want to optimize for cache locality you need to eliminate indirections and allocate things close to each other. So you need to pack your data into typed arrays.
However if you only use object within a function (including all functions compiler managed to inline into that function), and you don't put it into some collections, but use it directly - then such object will "explode": compiler will eliminate the object and turn its fields into local variables
I assume the question is about Dart VM, not JS or Wasm.
In technical terms: there is no stack allocation, but there is scalar replacement of aggregates. In simple terms: if you have an object and you pass to another function (which is not inlined) that object has to be heap allocated.
What is your biggest gripe with build runner? Would you be happy if it runs 10x faster and the code does not have all the pesky `$` and other boilerplate nonsense?
Would you prefer to wait couple more years for macros to ship? What was your specific use case you were betting on macros?
We are hoping to address most gripes (e.g. data classes, serialization, build_runner slowness) on a much shorter time frame than what macros would have taken us.
We have unfortunately decided to stop working on macros.
You can read the statement here: medium.com/dartlang/an-...
Feel free to ask me any follow up questions.
Spent some recent downtime hacking. A TodoMVC with Web Asssembly & server-side rendering using the impressive Jaspr framework:
vsm-todomvc-wasm.web.app
Very cool to see this working on Chrome, Safari, and Firefox - Wasm has come a long way!
Based on few request I also wrote about my reading aspirations for 2025: mrale.ph/blog/2025/01...
We are looking for stellar Dart and Flutter developers to join our team in Stockholm (or possibly remote). Check our website for all open positions! 🧑💻
careers.serverpod.dev
In 2024 I have finally managed to reboot my book reading habits and as a result read more than in 4 previous years combined.
As the year draws to a close I have decided to look back at the books I have read to reflect on them a bit
mrale.ph/blog/2024/12...
I think this must mean that analyzer is busy with other tasks for some reason. I will return to this in the NY after holidays.
Can you also post details of slow requests by clicking on them? They should have breakdown of what took time. You can obscure names (but there should not be many private names there)
When you hit long requests could you open Analysis Server diagnostic page and post information about request latency from there?
Is there a bug / more details for this?
I have not worked on it. "Small issues in the translation layer" is a tad vague - might be bugs, might be intentional discrepancies (e.g. number system is slightly different for efficiency reasons). Hopefully 10 years down the line we will only need to support Wasm as a target and deprecate JS one
You mean new analyzer plugins system? The answer is here:
github.com/dart-lang/sd...
That's a fair request. Not much else I can say about this :)
You should ask Flutter folks why they decided to ignore Dart style recommendation and add this useless `k` upfront.
I would like to have something in ~Q1 which would at least improve our visibility into perf problems. Right now we can't even say what is slow in @roszkowski.dev case if we can't repro it.
