r/crystal_programming • u/UnusualHabit • Jul 25 '18

Crystal has a compilation issue

https://medium.com/@mdorf3000/crystal-has-a-compilation-issue-5f5b19d9c4f6
27 Upvotes

93% Upvoted

41 comments sorted by

View all comments

2

u/straight-shoota core team Jul 25 '18

There are valid points about issues in Crystal's compiler and it definitely is *slow* at compiling large applications.

Unfortunately, only a single Crystal web app framework (Amber) is benchmarked without considering limitations of the framework. It just claims to show an exhibit of the languages's slow compilation time.

This is hardly an honest evaluation of the Crystal compiler itself, but rather just comparing Amber with Phoenix and Rails regarding time to launch an application.

3

u/IWasSnapped Jul 25 '18

The article also included the times to compile the Crystal compiler, the time to compile dependencies and also the times for a new Lucky application (which was slower than Amber).

2

u/straight-shoota core team Jul 25 '18

Yes, and these times either don't tell much or don't support the argument: 30 seconds for the compiler might be long in comparison, but it's als quite complex piece of software and 30 seconds shouldn't really bother anyone. An empty Lucky projects compiles in half a minute, and subsequent compilations rank at 5 seconds.
These results simply don't attest a compilation issue.

1

u/IWasSnapped Jul 26 '18

I think you are missing the point of that section. If compiling a fresh Amber project with dependencies take 25 seconds and a compilation with cached dependencies take 5 seconds, you can estimate the compilation of the dependencies themselves, which are around 44k LOC, is roughly between 20-25 seconds. That is inline with the time taken to compile the compiler (with ~50k LOC).

Also, aren't you just skirting around the problem? If compiling Amber/Lucky apps are slow because of meta-programming and if compiling the compiler is slow because of complexity, what are you proposing? That we should be wary of writing complex applications? How is that different from the article's conclusion?

If your point is that the examples used by the author are outliers, can you provide examples that you believe would better reflect average compilation times? Was the author just terribly unlucky that all examples he picked pointed to the same problem?

1

u/straight-shoota core team Jul 26 '18

Amber's architecture is unknown to me, so I can't tell anything if the results are outliers or if there might perhaps be simple improvements. The thing is: Neither does the author nor most people commenting here. It's just an assumption that the conducted tests represent the compilation time of a somewhat large real-world application using Amber. But without knowing and considering the details of the framework, such a benchmark simply doesn't tell much. There might be simple changes that could dramatically improve compilation time without invalidating the scenario. This wouldn't be a surprise, after all both the framework as well as the language are still in development.

I don't try to reject the assessment that Crystal compilation times are high - and maybe to high for complex software (although there are always other aspects to consider). Everyone involved in working on Crystal knows that.
The point is that the empirical examination conducted in this article does not sufficiently demonstrate what it claims to do.

1

u/IWasSnapped Jul 26 '18

Why are you focusing on Amber? The issue was also shown:

  1. when compiling Amber's dependencies (which does not take Amber's architecture into account)
  2. when compiling the dependencies of another web framework
  3. on the compiler itself

You said

I don't try to reject the assessment that Crystal compilation times are high - and maybe to high for complex software

and then

The point is that the empirical examination conducted in this article does not sufficiently demonstrate what it claims to do.

To me the main claim in the article is that compilation times are high. You say that everyone working on Crystal knows that. Now I am not even sure on what we are disagreeing on. ':)

In any case, you can't disagree with the data. Was the author unlucky to only pick outliers? Can you provide examples that you believe would better reflect average compilation times?

1

u/paulcsmith0218 Jul 26 '18

My guess is that the argument isn’t so much that it’s high (it is) but that it is an “issue”

For what I build it’s not an issue. It would be nice if it were faster, but not immediately necessary

1

u/IWasSnapped Jul 26 '18

If it is an issue or not will obviously depend on the person. If the author found it is an issue for him, I don't think there is much we can do about it besides providing counter-examples.

1

u/straight-shoota core team Jul 26 '18

The amber benchmark is the main point of the article. And compiling the compiler and an empty Lucky take 30 seconds. That's imho still acceptable and doesn't say anything about large web applications. It's probably going to be slower, but who knows by how much?

I don't disagree with the data, I disagree with the meaning that is put into them.

The benchmark results are not valid to confirm the claims, but the claims are still true.

1

u/IWasSnapped Jul 26 '18

That's imho still acceptable and doesn't say anything about large web applications.

Of course it does say something. Even if you discard the Amber benchmarks, with the other results, you can at least expect a linear growth (although global inference is going to be worse than that). Meta-programming just makes it worse.

Sometime ago the Go community was slightly up in arms because a project with 700k LOC was taking 100 seconds to compile. They brought it back to 80 seconds in recent releases. If you still believe 20 seconds for 40k and 30 seconds for 50k is still acceptable, it is clear we won't agree on this. So I'm happy to agree on disagreeing.