The Cost of Small Methods

Ktistec uses a template engine^† for it's views.

View templates are transformed into Crystal code that generates HTML when executed. As you'd expect, the template language allows you to use string interpolation syntax (e.g. #{expression}) for dynamic values.

To ensure expression is only evaluated once, and to limit the scope of the temporary variable holding the evaluated value of expression, I originally bound the value to the variable using Object#tap (commit 5e1bf19e). The generated code looked something like:

(expression).tap do |__value__|
   <template code that uses expression>
end

Blocks in Crystal are always inlined, so the code above should be equivalent to the following (sacrificing local scope):

__value__ = (expression)
<template code that uses expression>

Functionally, they are equivalent. But operationally, not so much! With Object#tap, the Ktistec executable is about 1% larger (36823603 bytes vs. 36526307 bytes) and build times take 20% longer (23 seconds vs. 19 seconds, generally).

In total, view templates represent about 6% of the Ktistec executable by size, so it doesn't surprise me that there's a measurable impact when I make changes to the template engine, but wow...! I can almost live with the size of the executable, but the build time...!

The cost has to be the method call.

What I'm looking for is something like let in Scheme. The following macro comes close, but doesn't limit scope quite the same way:

macro let(expr, &block)
  {{block.args.first}} = ({{expr}})
  {{block.body}}
end

I maybe have to live with the macro—I tried to implement let as a method with the annotation @[AlwaysInline] but there was no improvement over the original.

^†The template engine is a fork of Slang—which I've been evolving to be more Slim-compatible.

#ktistec #crystallang

i'm always happy when i see a new release of #crystallang

https://github.com/crystal-lang/crystal/releases/tag/1.11.0

awesome work!

i've been following hashtags for a while now. i turn off shares (boosts) and replies so they don't appear in my timeline (there's too much sharing going on out there), but then follow a handful of hashtags (like #woodworking and #crystallang and #boardgame) to see more of what i like!

#ktistec

I've been tracking epiktistes inbox/outbox traffic and memory statistics (as reported by the Boehm garbage collector) for a while. There's always a consistent increase in both heap size and free memory—to the point where reported free memory is greater than the originally allocated heap—though the difference between the two doesn't appear constant over time. At the moment, heap seems to have plateaued but (pessimistically) I don't expect it to remain flat.

Given relatively flat traffic, the growth in free memory is surprising. I haven't had a chance to investigate, but based on what I understand about Boehm the increase in free memory could be due to increased fragmentation, and the growing difference between heap and free memory could be due to the conservative nature of the garbage collection algorithm.

Or there could be legitimate memory leaks. I did find one, months ago, which was the result of caching SQL prepared statements (in a Hash) and poor practice constructing queries in a couple places, which led to nearly linear growth in cached statements. The difference then was that heap growth was much more consistent, which is not what I see here, now.

#ktistec #crystallang

fdescribe/xdescribe, fcontext/xcontext, fit/xit have really been game changers during tdd. previously, i specified specs to run by line number, which works but requires me to hunt down the line number... i don't know why it took me so long to adopt this—i guess i assumed spectator didn't support them.

#crystallang #spectator

the crystal programming language always inlines blocks, which is great for performance but trades off space for speed. using blocks effectively means keeping this in mind.

somewhere along the line, i learned the habit of passing a block to a function as a means of customizing the behavior of the function. if the function that takes the block is large, it's important to remember that the body of the function is inlined where the function is called, which may not be what you are expecting. if you call the function multiple times, you even get multiple copies.

i just committed code that fixes an egregious example of this problem. in this case these ~30 lines of code replace the blocks with procs (which aren't inlined) and cut ~24mb (that's megabytes) off the executable (over a third of its size).

i regularly shoot myself in the foot trying to be clever, so i don' t know how prevalent this problem is in practice, but it's definitely something to keep in mind, especially if you see compile times and executable sizes growing!

#crystallang #ktistec

...well, for future reference, Invalid memory access (signal 11) at address 0x7ff7b19429f8 likely means the application has overrun its stack, especially if the stack trace shows even moderate recursion.

about the recursion though, this error happened after only 5 recursive calls (not 50,000) and that caught me off guard. i've been recently conditioned to think the stack only holds primitive values and references (pointers) but crystal, like c and similar languages, lets you pass around structures (instances of struct) by value and those values can be arbitrarily large.

now i need to figure out how to debug the contents of the stack...

#crystallang

til... the following works in #crystallang

[{1}, {2}, {3}].sort_by(&.first.-) # => [{3}, {2}, {1}]

because - is a method that returns the negative value of the number on which it is called. (the tuple in the example is obviously contrived...) this is in contrast to the following, which do the same thing but are more verbose:

puts [{1}, {2}, {3}].sort_by { |t| -t.first } 
puts [{1}, {2}, {3}].sort_by(&.first).reverse

one of the crystal programming language’s greatest strengths is the ease with which you can work with c apis and external libraries without leaving crystal. you can even implement callbacks in crystal!

in sqlite you can define new functions—callable from sql—with sqlite3_create_function by providing a name and a callback that implements the function. i created a new function called strip, entirely in crystal, that removes html markup and leaves text. it can be used in a sql query like so:

select * from objects
where strip(content) like "%term%"

it’s part of the recently released content filtering code.

#crystallang #ktistec