Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That complaint was weird, here's my day 7 solution in zig built in release mode:

    $ time zig build-exe ./a.zig -O ReleaseSmall

    real 0m1.728s
    user 0m1.544s
    sys 0m0.292s
Which is actually slower than running the entire solution in debug mode:

    $ time zig run a.zig -- input.txt
    min 337 342641
    min 470 93006301

    real 0m1.138s
    user 0m0.789s
    sys 0m0.270s
Totally possible that it's much slower on the dev's machine, but if he's a VR developer it seems weird that he'd have a low-powered box.

[1]: https://github.com/llimllib/personal_code/blob/master/misc/a...



Blog author here. I'm an Intel i7-8700k desktop. A few years old at this point, but quite beefy.

Maybe this is a Windows issue? If I run "zig build" and then immediately run "zig build" again it still takes 3 seconds.


A relatively quick way to test that theory might be to pull down a WSL2 image of some sort and run the same thing in there.

Speaking as somebody who mostly codes for *n?x but has some windows users of their libraries, I've run face first into "everything I know about build optimisation is inapplicable on windows" more than once.

('everything' is admittedly slightly hyperbolic but I'm sufficiently bad at windows tooling that it always feels that way)


Sounds like something is messed up with your zig cache. I have a medium-size project (30 files, 10s of thousands of lines of code) that takes 0.07 seconds to `zig build` if nothing has changed. This is on a Mac.


How do I clean the zig cache? There does not appear to be a "zig clean".


rm -rf zig-cache over here


Ah didn't realize it was just a folder in the project directory, oops!

Nuked zig-cache and zig-out, rebuild, no change in build times.


Totally possible! I don't have a Windows box to test on, and win does sometimes end up as a second class citizen for stuff like this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: