iiinova — where your digital self keeps evolving

mrale.ph @mrale.ph · 02/06/2025

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.

010

mrale.ph @mrale.ph · 31/05/2025

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.

110

mrale.ph @mrale.ph · 31/05/2025

(Also our compilers are focused on code size so we avoid any optimizationa that expand code size)

020

mrale.ph @mrale.ph · 31/05/2025

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.

221

mrale.ph @mrale.ph · 24/02/2025

throw is an expression returning Never, so that you could write a ? throw B : c; among other things

040

mrale.ph @mrale.ph · 08/02/2025

(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).

010

mrale.ph @mrale.ph · 08/02/2025

I think bsky.app/profile/mral... answers it. It has to be created and used and not escape confines of a function*

110

mrale.ph @mrale.ph · 08/02/2025

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.

010

mrale.ph @mrale.ph · 08/02/2025

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.

en.wikipedia.org

Escape analysis - Wikipedia

110

mrale.ph @mrale.ph · 08/02/2025

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.

110

mrale.ph @mrale.ph · 07/02/2025

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

120

mrale.ph @mrale.ph · 07/02/2025

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.

120

mrale.ph @mrale.ph · 07/02/2025

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

220

mrale.ph @mrale.ph · 07/02/2025

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.

120

mrale.ph @mrale.ph · 29/01/2025

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?

100

mrale.ph @mrale.ph · 29/01/2025

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.

100

mrale.ph @mrale.ph · 29/01/2025

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.

medium.com

An update on Dart macros & data serialization

We have invested significant time and resources to prototype macros over the past couple years. Unfortunately, each time we solved a major…

5275

Reposted by @mrale.ph

Vijay Menon @vsmenon.bsky.social · 06/01/2025

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!

2164

mrale.ph @mrale.ph · 06/01/2025

Based on few request I also wrote about my reading aspirations for 2025: mrale.ph/blog/2025/01...

mrale.ph

Reading in 2025

041

Reposted by @mrale.ph

Serverpod 🚀 @serverpod.dev · 03/01/2025

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

0113

mrale.ph @mrale.ph · 29/12/2024

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...

mrale.ph

My year in books

2130

mrale.ph @mrale.ph · 20/12/2024

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.

020

mrale.ph @mrale.ph · 20/12/2024

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)

110

mrale.ph @mrale.ph · 19/12/2024

When you hit long requests could you open Analysis Server diagnostic page and post information about request latency from there?

100

mrale.ph @mrale.ph · 17/12/2024

Is there a bug / more details for this?

100

mrale.ph @mrale.ph · 17/12/2024

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

140

mrale.ph @mrale.ph · 17/12/2024

That's a fair request. Not much else I can say about this :)

110

mrale.ph @mrale.ph · 17/12/2024

You should ask Flutter folks why they decided to ignore Dart style recommendation and add this useless `k` upfront.

120

mrale.ph @mrale.ph · 17/12/2024

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.

140

mrale.ph @mrale.ph · 17/12/2024

Current best practices is to use pub workspaces and to avoid barrel files and large strongly connected components in the import graph.

350

mrale.ph @mrale.ph · 17/12/2024

We don't have a dedicated security team, we lean on expertise of various other security teams when we need it.

010

mrale.ph @mrale.ph · 17/12/2024

I am not sure how to answer this, you would need to elaborate. I am not sure I feel about it in any particular way. It exists, it does its job despite JS being not so good a compilation target for Dart.

100

mrale.ph @mrale.ph · 16/12/2024

here we go again (I will now do this every 2 months on ~16th): reply to this tweet to AMA about @dart.dev or complain about anything @dart.dev related. I will do my best to reply.

104414

mrale.ph @mrale.ph · 10/12/2024

Breaking change for marginal benefit? You don't have to fix all bad design decisions. Some are more worth fixing then others.

120

mrale.ph @mrale.ph · 10/12/2024

You mean that we regret not having proper marker interface for toJson? Yes, you can quote me on that :)

220

mrale.ph @mrale.ph · 09/12/2024

I think it should only go into dart:core if there is a language semantics associated with it. If there is no language semantics - it should just go into a package. There is some level of desire to support Disposable through language constructs - but timeline is unclear at this point.

110

mrale.ph @mrale.ph · 09/12/2024

I don't understand what the the question means. Mixins can implement interfaces. Well, I understand "just pass" part. It is convenient - but I think it is questionable API design. I can't stop you from doing it - but I will not do such thing myself :)

100

mrale.ph @mrale.ph · 09/12/2024

It's a one time cost. I don't have a number. Probably for this particular case it is not very significant - but it is something to be aware of in general. For methods with parameters this might cause cascading effects as well and regress code quality of those methods - doesnt apply to dispose though

010

mrale.ph @mrale.ph · 08/12/2024

also strategy pattern and your own marker interface create much better typing for the API - because this becomes explicit in the function signatures, rather than you putting something in the comment about how class having a dispose method changes behavior of your methods.

000

mrale.ph @mrale.ph · 08/12/2024

That's why I said that your own marker interface (maybe living in a separate package) and a strategy pattern should give enough flexibility here. Traits might be better - but Dart does not have traits, so strategy is your best choice.

100

mrale.ph @mrale.ph · 08/12/2024

Well, you can't add all marker interfaces you'll at some point want to the core libraries. I think Disposable only belongs to dart:core if we add some specific semantics associated with it. So you should think about the ways to solve this without changes to dart:core.

200

mrale.ph @mrale.ph · 08/12/2024

Tearing off a method introduces a method extractor helper and a body of the extracted method (which redirects to original method) - both of these will contribute to the code size even if you don't actually add any additional reachable methods (assuming that all dispose methods are retained anyway)

110

mrale.ph @mrale.ph · 08/12/2024

Not adding a proper marker interface for toJson, as I said, was a mistake. (though it is important to understand that Dart 1 was much more dynamic compared to Dart 2 so using dynamic dispatch like this was not perceived as an issue).

110

mrale.ph @mrale.ph · 08/12/2024

And to answer your second question: yes, in general you should assume that any dynamic function calls impact tree-shaking and they should be avoided (unless by chance it turns out that TFA can infer a good receiver type for them - but you should not assume / rely on this).

030

mrale.ph @mrale.ph · 08/12/2024

Checking for a presence of a method with a specific name and making assumption that it fufils some contract is a very "weakly typed" / JavaScripty approach. Dart's core library made this mistake with toJson and we regret it greatly.

360

mrale.ph @mrale.ph · 08/12/2024

You have an option of introducing a your own interface (if possible to ask users to extend it) or to use some variation of a strategy pattern (when the caller supplies both object and the way to dispose it). The combination of both probably gives the best experience.

130