Does omitting types in method parameters affect compiler speed?

[girng_github]

I’ve always been curious about this!

For example:

# NOT SPECIFYING TYPES IN PARAMETERS
#class Client
#  property username : String
#  property id : Int32
#  
#  def initialize(username, id)
#    @username = username
#    @id = id
#  end
#end

# SPECIFYING TYPES IN PARAMETERS
class Client
  property username : String
  property id : Int32
  
  def initialize(username : String, id : Int32)
    @username = username
    @id = id
  end
end


p = Client.new("Muffin", 9000)

pp! p

Both variations of Client compile without issue. And I don’t think just ONE class would affect the compiling process, however… it got me thinking; does it affect it at a large scale? Let’s say you have 50, 70 or 100+ methods that don’t specify the types in parameters. Does it make a difference?

[vlazar]

When you have a question about speed, the best thing to do is ask a computer.

No matter how smart you think you are, you will be just making assumptions of how fast this piece of code is or will x be faster than y.

Sure, you can use Big-O notation to some extent but the best thing is still to observe and make conclusions. This is how science works.

So make your experiments and let those theories meet the reality. Learn from it!

See for example this cool optimization done by Ary for Hashes which is landed in Crystal 0.31.0

Hash now uses an open addressing algorithm

I found this part very interesting:

The compiler uses Hash all over the place!

So compile times now should go down! Right? … Right?

Well, unfortunately no. I think the main reason is that the times are bound by the number of method instances, not by the performance of the many hashes used.

Memory consumption did seem to go down a bit.

Here is assumptions about faster Hash implementation providing better compile time due to excessive usage of hashes by compiler met the reality.

The lesson learned.

So in your particular case

1. It is very easy to make a small program and generate tons of source files
2. Then do a benchmark. This will be harder as benchmarks are not so easy to do right. You have to exclude other factors which may affect results.
3. And then make your conclusion. This one could also be hard.

[vlazar]

I’ve remembered reading this article a while ago which is fascinating:

https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables

A deterministic hash table proposed by Tyler Close was implemented in C++ and its performance was compared to two hash table implementations using open addressing. Speed and memory usage were measured.

Here is the cool part:

Speed. The Close table implementation was very fast, faster than the open addressing implementations. (It is unclear why; theory suggests it “should” be slower, and measurement confirms that the Close table is doing more memory accesses and more branches. More investigation is needed!)

So just benchmark your code. This is the way to go.

[girng_github]

Hi @vlazar, thanks for the info!

If I use Benchmark.ips to compare those two class Clients would that work? Or would I need a “compiler benchmark” tool?

[vlazar]

Since your question was about compilation speed and Benchmark.ips is a runtime thing, you can’t put classes inside Banchmark.ips and expect it to somehow measure compile speed.

The thing inside Benchmark.ips needs to be executed. So yeah, some kind of tool would help you avoid measuring compilation speed manually.

You might wanna take a look at https://github.com/manastech/benchy by Brian.

[asterite]

My guess is that compile time difference will be negligible. Ommiting types should be slightly faster but not noticeable.

[girng_github]

Alright sweet. Thanks for the input on this matter. I don’t feel as curious as before.