Crystal: [Suggestion] Compiler option to disable specific APIs

[girng]

In Godot, when compiling, there is an optional flag to disable specific classes/modules.

This made think of an idea for Crystal. For my project, there are about 20 or so modules that are not needed (they range from ECR, HTML to Zlib).

If the developer could disable specific modules _with a compiler option_, and if this decreases compile times, I think this could benefit Crystal very well. Not only now, but for the future moving forward.

Mock-up image to better explain the suggestion:

[bcardiff]

If the module is not used the parsing is the only thing that will happen.

If you found that compile times improve significantly by disabling some modules then it might be worth considering.

You can try it out by either:

1. editing the prelude.cr file and removing some modules.
2. Removing the whole prelude and requiring your own. Pass --prelude=none

[girng]

Hi @bcardiff, thanks for the info.

I tried my own prelude (--prelude ./prelude.cr) and disabled some modules, but it seems like these are the heart of the program.

If the module is not used the parsing is the only thing that will happen.

I see. Essentially, if a developer does not add require "module", it effectively is my suggestion? As it's an opt-in functionality? Wait, my suggestion doesn't make sense then

[r00ster91]

I think we should trim the prelude down to the absolute minimum and only leave the very basic stuff in and then the user can decide with additional requires what else is needed. Doing that would be very beneficial to improve the compile times that are already long from the very beginning.
There is some unnecessary stuff in the prelude that you most of the time don't need, like Humanize for example.

[jhass]

Please prove this actually has any benefit, again, parse time is not the bottleneck here and codegen only happens for actually called things.

[r00ster91]

Then why isn't every library in that prelude already? It makes no sense to have libraries like Humanize in there but not others.
Also more requires makes your program better to read because the requires at the start can give you a rough idea of what the program is going to do. I think it's better to have more control.

Also I don't agree with

and codegen only happens for actually called things.

because:

$ crystal build file.cr --release
$ ls -l file
-rwxrwxrwx 1 r00ster r00ster 719192 Oct  1 15:01 file
$ crystal build file.cr --release
$ ls -l file
-rwxrwxrwx 1 r00ster r00ster 719336 Oct  1 15:01 file

In the first build file.cr was empty. In the second there was require "string_scanner" in it.
Notice the difference of the size before and after: 719192 and 719336.

So executable size would benefit from this as well. Which definitely needs to be improved.

[r00ster91]

Actually, compiling with --no-debug solves the file size difference. No clue why this flag is needed to strip out something that is never needed in the executable.

[asterite]

Which libraries you want out of the prelude? Current libraries are the minimum needed for the runtime. I think this issue should be closed.

[r00ster91]

No, they aren't at the minimum. require "humanize" and require "va_list" and a few other files are unnecessarily in the prelude.

[asterite]

Let's also remove any String API that's not strictly used by the runtime. I don't think this proposal is relevant, there's no performance difference and 320 bytes in executable is nothing.

[asterite]

Until someone can frame this as "I need to remove humanize from the default requires because when I compile my project I see a 5 seconds difference without it" changing this is more of a hassle than a benefit.

[j8r]

But then, what's the point of having requires for the stdlib then?
The design should be consistent, - not everything is about performance.
Either "all batteries are included" (no need of require "ini", require "logger"...) or not, but not partially for some modules and not others.

[Sija]

@j8r In the current design both of these options are simply unfeasible and the current state of things is a compromise between them both - what's the point of arguing about it without a better, solving real problem alternative - and not imaginary, "ideal world" perceptions about "how things should be".

There's enough arguments against having to include _everything_ by urself and the same goes for "batteries-included" approach - which is seen by many as a bloat - and with a good reasons (kb).

[girng]

I downloaded the source and got everything working after fixing the LLVM issues. Thank god to WSL's new editing server for unix files.

This suggestion doesn't make sense because all the "classes/modules" I listed (ECR, HTML, etc) are opt-in only. I thought all of them were in the final executable after compiling from source (which isn't true). I am sorry, I should have looked into this before making this issue.

[ysbaddaden]

Closing. Prelude is already the minimum required by the compiler for all programs to run.

The humanize require is merely because it groups a few methods together that would otherwise be in the types they extend (i.e. Number, String).

You may open independent issues, for example about IO loading all IO, but since it's a mere 4 or 5 files, improving performance by only a few milliseconds at best, that probably won't lead anywhere.