kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
factormystic has joined #sandstorm
nicoo has quit [Remote host closed the connection]
nicoo has joined #sandstorm
<isd>
reminder: office hours in 10 min
<kentonv>
the vagrant environment for testing the sandcats server has thoroughly bitrotted. Do I try to build a new one, or do I just yolo-update the server with my fairly-small patch?
<kentonv>
I guess the nice thing about the sandcats service is that if it breaks, it takes 12-72 hours before anyone is really affected
<zarvox>
sandstorm dev-shell performance feels noticably slower to update on client-side code change recently; I'm wondering if the node/meteor 1.9 update might have made things slower for our setup for some reason
<zarvox>
I think I might have to make sandstorm run node with the "dump a jit map" flag to get useful symbols for this?
ocdtrekkie has joined #sandstorm
<zarvox>
looks like it's all getting spent in RegExp in meteor-tool's copy of babel
<zarvox>
I guess I'll just live with this being a bit slower
<kentonv>
maybe related to turning on typescript, rather than Meteor 1.9?
<zarvox>
this is odd because I don't recall such poor incremental rebuild performance on my other projects using typescript throughout
ocdtrekkie has quit [Read error: Connection reset by peer]
<zarvox>
My current inclination is to backpedal on typescript for now since I anticipate that we'll have to do substantial cleanup to be able to make appreciable use of it, and we can get a lot of the same benefit by doing general cleanup and getting to a place where we can pass a decent set of eslint rules
<zarvox>
oh wait hold on my testing methodology might have been bad
<zarvox>
was still modifying main.ts after the revert so of course my change didn't do anything
<zarvox>
let me try this again and get better data
<zarvox>
okay, I take that all back -- typescript revert did *not* appreciably change incremental build time
<zarvox>
nor the flamegraph shape
<zarvox>
betting this is just babel getting crufty over time, my memory being overly rosy of past performance, and maybe shifting regexp perf between node versions
<zarvox>
at this point this is far enough upstream that I'm willing to just deal with things being a little slower. we can also try seeing if meteor 1.10.1 improves anything on this front
<zarvox>
thanks for letting me rubber-duck :)
ocdtrekkie has joined #sandstorm
<isd>
I'm pretty grumpy about meteor's build times in general, but I haven't noticed it get worse since I started hacking on core.
<isd>
Mostly off topic but: neat thing I discovered the other day about rust's build system: it puts a Makefile fragment in the target directory, so if you've got a cargo project that's part of a larger system, it's easy to get accurate dependencies for the rust code without having to do much work.
<kentonv>
I wonder if there's some way to tell Meteor to distribute the build over multiple cores
<kentonv>
(or does it already do that? I am just sort of assuming it doesn't)