The prologue to this post, and other posts in the series, is here.
Investigating commit b65d292f was fruitful but not for obvious reasons.
Dumping the symbols (nm -j server) before and after the commit showed large number of new equality (==) methods. From the diff:
1765a1772\n> _*ActivityPub::Activity::Accept#==<Translation>:Bool\n1920a1928\n> _*ActivityPub::Activity::Add#==<Translation>:Bool\n2062a2071\n> _*ActivityPub::Activity::Announce#==<Translation>:Bool\n2237a2247\n> _*ActivityPub::Activity::Block#==<Translation>:Bool\n ...
The use, in a controller action, of the new Translation model seemingly triggered their generation. What was going on?
A long time ago I implemented a MVC model framework in the style of ActiveRecord (2de4a4b3) and it included a method for testing for equality. Note the method signature.
# Returns true if all properties are equal.\n#\ndef ==(other : self)\n {% begin %}\n {% vs = @type.instance_vars.select(&.annotation(Persistent)) %}\n if\n {% for v in vs %}\n self.{{v}} == other.{{v}} &&\n {% end %}\n self.id == other.id\n true\n else\n false\n end\n {% end %}\nendThe Reference class—the default parent for classes—defines two base implementations of this method: one that tests for identity (not equality), with the signature def ==(other : self), and another that returns false, with the signature def ==(other). When I implemented my method, my assumption was: redefine the former for model classes and let the latter take care of everything else. This assumption was incorrect.
In circumstances that I still don't completely understand, the compiler will generate calls to the latter (the method that just returned false) when it \"should have\" been calling the former, and comparisons failed when they should have succeeded. I \"fixed this\" with commit effeaa26 that removed the type restriction and explicitly handled the type check. Everything worked!
The problem is Crystal creates a version of this method for every possible model comparison, specialized by both self and other. Most of the time the type check fails and the method returns false. But the rest of the code is still present.
The fix (re)adds a method specialization that returns false and lets the compiler handle the type check.
# Returns `false`.\n#\ndef ==(other)\n false\nend
Because this method just returns a constant value, the compiler gets rid of the method call, as well.
Interestingly, this change reduced the size of the Ktistec server executable by 4.0% when building without the --release flag but only 0.2% when building with it, so optimization does a good job at cleaning this up even without the change.
The prologue to this post, and other posts in the series, is here.
Investigating commit b65d292f was fruitful but not for obvious reasons.
Dumping the symbols (nm -j server) before and after the commit showed large number of new equality (==) methods. From the diff:
1765a1772\n> _*ActivityPub::Activity::Accept#==<Translation>:Bool\n1920a1928\n> _*ActivityPub::Activity::Add#==<Translation>:Bool\n2062a2071\n> _*ActivityPub::Activity::Announce#==<Translation>:Bool\n2237a2247\n> _*ActivityPub::Activity::Block#==<Translation>:Bool\n ...
The use, in a controller action, of the new Translation model seemingly triggered their generation. What was going on?
A long time ago I implemented a MVC model framework in the style of ActiveRecord (2de4a4b3) and it included a method for testing for equality. Note the method signature.
# Returns true if all properties are equal.\n#\ndef ==(other : self)\n {% begin %}\n {% vs = @type.instance_vars.select(&.annotation(Persistent)) %}\n if\n {% for v in vs %}\n self.{{v}} == other.{{v}} &&\n {% end %}\n self.id == other.id\n true\n else\n false\n end\n {% end %}\nendThe Reference class—the default parent for classes—defines two base implementations of this method: one that tests for identity (not equality), with the signature def ==(other : self), and another that returns false, with the signature def ==(other). When I implemented my method, my assumption was: redefine the former for model classes and let the latter take care of everything else. This assumption was incorrect.
In circumstances that I still don't completely understand, the compiler will generate calls to the latter (the method that just returned false) when it \"should have\" been calling the former, and comparisons failed when they should have succeeded. I \"fixed this\" with commit effeaa26 that removed the type restriction and explicitly handled the type check. Everything worked!
The problem is Crystal creates a version of this method for every possible model comparison, specialized by both self and other. Most of the time the type check fails and the method returns false. But the rest of the code is still present.
The fix (re)adds a method specialization that returns false and lets the compiler handle the type check.
# Returns `false`.\n#\ndef ==(other)\n false\nend
Because this method just returns a constant value, the compiler gets rid of the method call, as well.
Interestingly, this change reduced the size of the Ktistec server executable by 4.0% when building without the --release flag but only 0.2% when building with it, so optimization does a good job at cleaning this up even without the change.