Lots of exercise time out

I have several exercises that timeout in the browser that work fine (and fast) locally.

I’ve seen suggestions that infrastructure could be at fault sometimes, but that doesn’t seem to fit the data here.

Could the tolerances be too tight? Maybe it’s just not cost effective to loosen them?

I was hoping to recommend this site to co-workers as a place to learn more about Rust, but these timeouts are giving me pause.


I’d need some more info about that solution of yours. What’s the exercise? Are you using dependencies and which ones?

Most timeouts (that aren’t an infra issue) are due to long compile times in my experience. And those are mostly due to heavy dependencies.

Edit: And that’s why I think the timeouts are theoretically fine the way they are - extending them would mostly enable heavier dependencies, which is not worth it imo. Users are free to use whatever dependencies they like and test locally.

so far i’ve comp leted 15 exercises w/o a problem

“acronym” times out having only 25 lines and w/ only the “regex” dependence that times out

“poker” times out – it has “regex” plus “itertools”, “strum”, and “strum-macros” – 430+ lines w/ additional tests

“forth” times out – it has only “regex” as a dependency – 320+ lines w/ additional tests and it runs in < 1 sec locally including the “alloc-attack” test

looking back over my completed exercises, none of them add any additional dependencies – so the common thread is “regex” which seems pretty routine to be the cause of timeout :confused:

so that got me thinking … i removed the use of “regex” from the “forth” exercise and it passed … hmmm

not being able to use “regex” seems like an undue limitation

There you go. I think it might be a good idea to remove these from the test runner, that should prevent some confusion. There’s no point in having a dependency in the test runner if compiling it always fails anyway.

I’m pretty sure strum-macros on its own would be enough to cause timeouts as well. I believe it pulls in syn which is notoriously slow to compile.

…on the other hand, I have a stale PR lying around to embed precompiled dependencies in the test runner. Hopefully that would solve the problem in some cases. Not sure when I’ll have time to get back to that.

I’m actually interested in your solution. I’ve never used regex for parsing in an actual programming language. To me, str::split for simple stuff or parser-comb libraries like winnow for complex stuff are the way to go.

working on replacement for regex in “poker” … we’ll see if it still fails due to the other dependencies

i could take a look at the precompiled libraries issue if that would help, but suspect that requires a fair bit of privilege

1 Like

removed “regex” from “poker” and it passed, even though it has the “strum” dependencies

Feel free, no priviledges necessary. It’s difficult though, I spent a lot of time on it and didn’t arrive at a solution with satisfactory trade-offs. If you’re serious about it, I recommend reading this thread of me talking to myself, should save you a lot of time.

re-implemented “acronym” w/o “regex” – only 20 LOC and no timeout – i like it better :rofl: