Great info about this release! After one guy who messed up with guidelines, mix format
would be a huge relief for me
BTW sorry that I reduced my activity this month, because ā¦ Iām on vacations, which means: taking care of my doughter
Great info about this release! After one guy who messed up with guidelines, mix format
would be a huge relief for me
BTW sorry that I reduced my activity this month, because ā¦ Iām on vacations, which means: taking care of my doughter
Some of my plans were changed, so I have free time that I spend on testing new features and enhancements in this RC, but I did not found problems. Of course I did not spend lots of time on every change. I just give them a try in my small private projects.
After fixing erlang bug it will be really good for me. Of course there will be lots of requests for formatting rules, but most of them could be solved by assigning some values to variables.
It would be awesome if my proposal would be implemented, but anyway now it looks ok.
The new formatter is a wonderful addition. But the change I am most interested in is the improved mix xref
.
I am working on a big Phoenix application, and compile times have reached a point when they are starting to get painful. Big recompilations are slow and frequent.
About a month ago I was able to use mix xref
to introspect the module dependencies and improve compilation times slightly. This week I started to play with Elixir 1.6 RC and the new options have helped me to find much more issues that I could not see before.
Introspecting the module dependencies on a big application is never an easy task, but with the new mix xref
options it is somewhat easier to filter and select what you want to see.
The thing that should help the most with big recompiles is that they will be prevented in many cases. Before 1.6 when a struct was used in a module, if the structās module was changed in any way, all the users were recompiled (since it produced a compile-time dependency).
In 1.6 the compiler tracks struct dependencies separately and only recompiles if the struct actually changed.
We should probably start getting some data on this.
Folks that are trying Elixir v1.6-rc.0, please run this in your projects and paste the first four lines here and also let us know if it is a Phoenix/Ecto/Nerves project.
For example, on Phoenix itself:
$ mix xref graph --format stats
Tracked files: 67 (nodes)
Compile dependencies: 22 (edges)
Structs dependencies: 26 (edges)
Runtime dependencies: 83 (edges)
Couple of phoenix projects:
Tracked files: 120 (nodes)
Compile dependencies: 199 (edges)
Structs dependencies: 55 (edges)
Runtime dependencies: 147 (edges)
Tracked files: 110 (nodes)
Compile dependencies: 289 (edges)
Structs dependencies: 30 (edges)
Runtime dependencies: 215 (edges)
Tracked files: 206 (nodes)
Compile dependencies: 308 (edges)
Structs dependencies: 85 (edges)
Runtime dependencies: 387 (edges)
Tracked files: 193 (nodes)
Compile dependencies: 357 (edges)
Structs dependencies: 52 (edges)
Runtime dependencies: 354 (edges)
So, in some cases itās about 12-25% of all compile + struct dependencies. And a huge amount of the compile dependencies are to the āwebā module - even a half of them. Subtracting the Web module (which changes rarely), the struct dependencies are 22-36% of compile + struct dependencies.
Two small Ecto + Phoenix projects:
Tracked files: 18 (nodes)
Compile dependencies: 12 (edges)
Structs dependencies: 8 (edges)
Runtime dependencies: 27 (edges)
Tracked files: 18 (nodes)
Compile dependencies: 19 (edges)
Structs dependencies: 0 (edges)
Runtime dependencies: 17 (edges)
Phoenix 1.2 project:
$ mix xref graph --format stats
Tracked files: 298 (nodes)
Compile dependencies: 577 (edges)
Structs dependencies: 111 (edges)
Runtime dependencies: 561 (edges)
A phoenix project (after some cleanup)
Tracked files: 266 (nodes)
Compile dependencies: 589 (edges) (down from 1006)
Structs dependencies: 52 (edges)
Runtime dependencies: 326 (edges)
Absinthe:
Tracked files: 216 (nodes)
Compile dependencies: 246 (edges)
Structs dependencies: 283 (edges)
Runtime dependencies: 609 (edges)
Large older Phoenix 1.2 app
Tracked files: 257 (nodes)
Compile dependencies: 174 (edges)
Structs dependencies: 91 (edges)
Runtime dependencies: 776 (edges)
I gotta find a way to lower those compile time depsā¦
So I just checked ecto and got:
Tracked files: 67 (nodes)
Compile dependencies: 40 (edges)
Structs dependencies: 31 (edges)
Runtime dependencies: 170 (edges)
I find it interesting in comparison to Absinthe - both projects are of similar size (absinthe is almost 11k LOC, ecto is 12.7k LOC), yet the file structure seems widely different.
mongodb
Tracked files: 27 (nodes)
Compile dependencies: 12 (edges)
Structs dependencies: 11 (edges)
Runtime dependencies: 44 (edges)
Phoenix Project
Tracked files: 54 (nodes)
Compile dependencies: 222 (edges)
Structs dependencies: 0 (edges)
Runtime dependencies: 13 (edges)
Meeseeks (library)
Tracked files: 88 (nodes)
Compile dependencies: 67 (edges)
Structs dependencies: 102 (edges)
Runtime dependencies: 77 (edges)
I didnāt know about this. It looks like a great improvement and will reduce both our recompilations and their time.
Is there any place where I can get more information on this matter? It is really interesting
On a prod-dependency-less library (no phoenix/ecto/nerves), based on exenv install master
@ commit ebe33f1f
:
$ mix xref graph --format stats
Generated mnemonix app
Tracked files: 34 (nodes)
Compile dependencies: 83 (edges)
Structs dependencies: 11 (edges)
Runtime dependencies: 64 (edges)
deps:
[
{:benchfella, "~> 0.3", only: [:dev, :test]},
{:cortex, "~> 0.4", only: [:dev, :test]},
{:credo, "~> 0.6", only: [:dev, :test]},
{:dialyzex, "~> 1.0", only: [:dev, :test]},
{:excoveralls, "~> 0.6", only: [:dev, :test]},
{:ex_doc, "~> 0.15", only: [:dev, :test]},
{:inch_ex, "~> 0.5", only: [:dev, :test]},
{:elastix, ">= 0.4.0", only: [:dev, :test]},
{:memcachex, ">= 0.0.0", only: [:dev, :test]},
{:redix, ">= 0.0.0", only: [:dev, :test]},
{:plug, ">= 0.0.0", only: [:dev, :test]},
]
It is limited on purpose, it is an example of what āshouldā be done, but I very much on purpose left it incomplete. ^.^
Pretty trivial to add, just not done as it was not needed to perform my example API.
I specifically donāt handle the case of it being called straight out to try to get people not to use it, it is just showing the API and how it should work. ^.^
Yep yep, showing how it works, those are the tests.
I started that work but stopped it so as to help minimize the use of the library.
Ditto, started that work but stopped it as well.
I ācouldā, but this library works by overriding def
itself, which I consider very poor form, and hence is also why I think this style belongs in Elixir itself, not as a library. It could be entirely functional, just I find overriding def
to be very very poor formā¦ ^.^;
Whoooo! Already using this. ^.^
Now if only the formatter would not destroy my nicely formatted and readable lists of numbers in a very specific format as well as my nicely format binary matching/building that practically matches the spec (though neither look like anything except a mess after mix format
is runā¦ >.<). ^.^;
It would be nice to have some sort of @verbatim
/ @endverbatim
to keep certain code sections as-is with mix format
, has this been discussed already?
Adding stats for a Phoenix (1.2) project thatās been in production for more than a year:
Tracked files: 179 (nodes)
Compile dependencies: 271 (edges)
Structs dependencies: 69 (edges)
Runtime dependencies: 448 (edges)
The number of compile and runtime dependencies seem to be much higher than the average. Should probably do some re-architecture to bring that down.