12:33 <nakilon> I'm running out of RAM; would s = Struct.new(:a, :b); millions.map{ ...; s.new(a, b) } be less time and memory consuming than [a, b] ?

12:34 <nakilon> I mean not "running out of RAM" but it gets slow after reaching 4gb, as usual

12:35 <nakilon> or nvm, it may be not the bottleneck

12:41 <nakilon> replacing this candles[a..b].map{ |_| [bx - _.x, _.y - by] }

12:42 <nakilon> with this candles[a..b].map{ |_| bx - _.x }, candles[a..b].map{ |_| _.y - by }

12:42 <nakilon> became almost twice faster

17:10 <havenwood> nakilon: While it's not technically reserved, `_` has special meaning in IRB and will overwrite your `_` if you `binding.irb` in so I'd avoid it.

17:10 <havenwood> By convention, it also means "unused" to prefix with `_`.

17:12 <havenwood> In latest stable, `map { it }` or in whatever supported Ruby `map { _1 }` instead. (Yeah, _1 not following the convention is weird as heck, but it's *mostly* replaced by `it` outside of `_1` with `_2` usage.)

17:13 <havenwood> A Struct or Data are indeed smaller than a two element Array. A `require 'objspace'` and `ObjectSpace.memsize_of` is handy for checking.

17:15 <havenwood> Twice the iterations, twice as fast. Object churn is expensive at scale.