support running inefficient programs in the vm

[disruptek]

What can I say? I'm not good at it and I have a lot of friends that write software even less efficient.

[juancarlospaco]

Why not just add {. intdefine .} and write end user documentation about how to set it.

[Araq]

Can you give us a reasonable example where this limit really hurts us?

[disruptek]

No, but it hurts me personally:

• I can't build any of the larger openapi inputs for the big cloud services without this change.
• I have to frequently stash patches and switch kernels every time I want to run a lot of openapi.
• We /want/ people to exploit the limits of the software and demonstrate all they can do in the VM; telling users they need to patch their compiler in order to build a complete AWS/EC2 API seems pretty discouraging.

Can you give me some painful examples where the limit helped? Should I be looking into my performance problem?

[timotheecour]

I have also run into this limit and had done the change locally (except as below):

• this should use:

const nimVMMaxLoopIterations {.intdefine.} = 10_000_000
const MaxLoopIterations = nimVMMaxLoopIterations

so that user can override, and so that we respect the nim prefix convention (pending nim-lang/RFCs#181)

• you also need to update this:

compiler/vm.nim:547:21:    "compiler/vmdef.MaxLoopIterations and rebuild the compiler"

and this: tests/vm/tmaxloopiterations.nim

[disruptek]

To be clear, I'm just trying to parse some JSON. Sure, it's not tiny, but under 100k lines, or about 4mb.

I don't think anyone should have to pass an option to the compiler if they want to consume a few hundred megs of data at compile-time. Maybe I'm alone in this view, however.

[timotheecour]

@disruptek the point is there is no "one true limit" (except unlimited but that would prevent catching certain bugs where VM runs in infinite loops for eg); what if your use case happens to be just above the new limit you put?

I did run into the existing limit (for a different scenario) and I welcome a PR that looks like #13135 (comment) (and ok if you change the default to something higher as part of the PR in addition to the intdefine)

[disruptek]

I've already made a PR to raise the limit for my use-case. If your use-case happens to be just above the new limit that I put, well, I also welcome a PR that looks like #13135 (comment).

But, to my eye, the fact that this PR is not that PR is not sufficient reason to reject it.

[timotheecour]

@disruptek I think #13233 is a better approach; it doesn't require recompiling nim to change the default max number of loops