just tested, this is nice, but in release mode longest is: [12/13] [0/1] Codegen (bc+obj) - 5 minutes, is there possible to create progress bar for it? may be even approximated, based on main obj file size.

It is great feature, however I would like to disable it by default because the compiler is quiet a long time ago. For instance, gcc (and I wish other compilers too) says nothing without warnings and errors on the default. This opinion comes from just a tradition, and I don't consider a usefulness for now. I agree of it to be enabled on shards by default because a build system is noisy a long time ago.

I think this should be enable on --verbose and when the stdout is an interactive tty

Oooh, nice!

@asterite Would you consider adding a progress tracker to crystal? If so, when should it be displayed?

@RX14 It does look right, but usually compilers and command line tools don't emit progress output unless requested.

I think the compiler should be faster so that a progress bar is not needed.

@asterite I'll change it to default to progress off.

Regarding neccesity, I doubt LLVM is going to get 10x faster, and LLVM makes up >50% of compile times for new builds (more for release, but progress tracking isn't useful there). While progress hopefully won't be necessary for incremental builds, it will be neccesary for initial builds I think. Regardless, this PR cleans up the statistics code a bit, and I don't think a progress indicator can be harmful.

Looks like a weird failure from osx.

Would have been nice to have this in 0.22.0, is there anything left to do?

Bump again :/
I'm sad I feel I have to do this. It's hard as a pull request author not knowing what the status of your PR is.

@RX14 Nice work :)
It's a really cool feature

@RX14 sorry for the delay with this. I think most of us simply assumed this opinion was enough feedback:

#4182 (comment)

Personally, I don't see any benefit to running with --progress as opposed to --stats.
In which scenario would you prefer running with --progress over --stats?

@mverzilli --progress has a cleaner output than --stats, with less profiling info (memory, exact times) and more progress info. For example, --progress shows the total number of stages before completion, whereas --stats does not. --progress also shows progress through the LLVM stage. It also updates the progress on the current line so as to use a single line of output instead of multiple, this makes your console history less messy as you don't see the progress output after the completion of the compiler.

Overall, --progress is useful for seeing progress while compiling, whereas --stats is useful for profiling the compiler.

I get the differences but still, if you want to see progress while compiling, --stats gets the job done.

Maybe we could add the total number of stages before completion to --stats, to give us a better idea of where we're standing?

Anyway, just my opinion!

@mverzilli --stats gets the job done (this PR also refactors stats to be cleaner), but it's not that much extra code to add this, and I can't see the maintenance cost being all too high either. There seems to be a lot of support for this (8 hearts!) and you can continue to use --stats. Why not merge it?

There seems to be a lot of support for this (8 hearts!)

Make that nine hearts!!

Personally, I would love this feature. --stats's output is kind of ugly for normal use, and, although most compilers are silent, usually I enjoy seeing the progress (helps a bit with my lack of patience!).

+1000000000 from me!

I'd simply say that --progress should stay simple (one-line, show progress only, no internal datas like memory or anything), so impatients like @kirbyfan64 (:smile:) will be able to keep track of the progression of the compilation for normal use, without having an ugly output (I agree it's really opinionated).

And --stat should be a "debug" for the compilation, with internal datas output (time, memory usage.. and there is room for other things too!), for thoses who wants precise informations about each compilation steps..

WDYT?

A lot of good arguments for this feature have been already covered, but I just want to point out that it's an easy feature to remove (it has no API surface) if for whatever reason it turns out to be a bad idea.

Given all the thumbs up for the feature, and since it is not enabled by default, and, as RX14 points out, it is easy to remove should it cause any troubles, I say we merge.

@RX14 This broke the current stats. Previously it would show, for example, "Codegen (crystal)" and then after some time print the time. This was useful to know in which stage the compiler were. But right now that's lost (it's printed all at once). Could you please fix it? :-)