The prologue to this post is here.
Investigating commit e2327eea might be a bust.
I dumped the symbols before and after this change. The new symbols were all specializations of the core library Hash class introduced by adding JSON parsing support for the \"language\" property.
So what does that mean and why is this commit a dead end?
You can think of Crystal classes and methods as being implicitly generics. If you have a method foo with one parameter bar and call it with an Array, Crystal creates a version of that method specialized to handle an Array type as an argument. If you call it with a Hash, Crystal creates another version of that method specialized to handle a Hash type as an argument. If the method has 20 lines of code, you effectively get two copies of those 20 lines of code. There is no runtime polymorphic dispatch, which is one of the reasons Crystal is so fast. You can make all of this explicit with Crystal type restrictions, method overloading, and generics, of course, but you don't have to.
This path is a dead end (for now) because any improvements that I can see that I can make (replacing hash construction with a more fluent sequence of attribute assignments) will need to be made to other classes where this is a problem, and there are only a few of those, so the net potential for improvement seems small.
", "contentMap":{ "en-US":"The prologue to this post is here.
Investigating commit e2327eea might be a bust.
I dumped the symbols before and after this change. The new symbols were all specializations of the core library Hash class introduced by adding JSON parsing support for the \"language\" property.
So what does that mean and why is this commit a dead end?
You can think of Crystal classes and methods as being implicitly generics. If you have a method foo with one parameter bar and call it with an Array, Crystal creates a version of that method specialized to handle an Array type as an argument. If you call it with a Hash, Crystal creates another version of that method specialized to handle a Hash type as an argument. If the method has 20 lines of code, you effectively get two copies of those 20 lines of code. There is no runtime polymorphic dispatch, which is one of the reasons Crystal is so fast. You can make all of this explicit with Crystal type restrictions, method overloading, and generics, of course, but you don't have to.
This path is a dead end (for now) because any improvements that I can see that I can make (replacing hash construction with a more fluent sequence of attribute assignments) will need to be made to other classes where this is a problem, and there are only a few of those, so the net potential for improvement seems small.
" }, "mediaType":"text/html", "attachment":[], "tag":[ {"type":"Hashtag","name":"#ktistec","href":"https://epiktistes.com/tags/ktistec"}, {"type":"Hashtag","name":"#crystallang","href":"https://epiktistes.com/tags/crystallang"} ], "url":["https://epiktistes.com/ktistec/performance/build-time-and-server-size-growth-2"], "type":"Note", "id":"https://epiktistes.com/objects/1XUauiuCrkg" }