XML parsing performance

[This PR](https://github.com/nim-lang/Nim/pull/17874) might be a good start. It is fundamentally an empirical question whether people will pay attention more (to anything, really). Might be worth backporting to expand the range/immediacy of the psychological testing. :-)

XML parsing performance

I assume that stacktraces will be unaffected, but it depends on what you mean by debugging. For me, I consider debugging to be mostly using gdb with the native debugging compiler option. But if you're talking about print debugging and using nim's stacktraces, that should be fine. >From [here](h

XML parsing performance

> **_SLOW, DEBUG BUILD_** ; -d:release to make code run faster. [BuildMode] Yeah, let's please use this solution.

XML parsing performance

The problem with `nim faster` is that it hijacks a slot presently used to select between backends..`nim c` vs. `nim js` vs. `nim cpp`. What about: Hint: 80712 lines; 1.693s; 147.246MiB peakmem [SuccessX] proj: file.nim; out: file [SuccessX] ***SLOW, DEBUG BUILD***; -d:relea

XML parsing performance

Maybe a command like "nim faster" which would just give a short synopsis of d:release and d:danger. It has been my experience that people do poke at command line options with "\--help and friends" even when they don't read the man pages or properly search for results on google/manual/stackoverfl

XML parsing performance

I agree. And if we choose release mode as default, some people will complain that there is not enough assistance when an error occurs.

XML parsing performance

I vote for staying with `-d:debug`. You debug a program much more often than release it. And most compiled languages do it like this.

XML parsing performance

IMHO it -d:debug stays the default the final message should very clearly and explicitly mention -d:release. However my vote is to change the default to -d:release as @Araq suggested. Experienced users can always shift to -d:debug when needed.

XML parsing performance

> Hmm, looks like opt:speed might interfere with debugging can you show such example (ideally reduced) ? I could see how that would be the case with `-d:nimStackTraceOverride --import:libbacktrace --debugger:native` (see also: `--passc:"-fno-omit-frame-pointer -fno-optimize-sibling-calls"` refs

XML parsing performance

Hmm, looks like `opt:speed` might interfere with debugging. Maybe we could have a new optimization flag for increasing speed of debug code? There's a gcc flag called `-Og` that increases speed without hindering debugging. From [here](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) > -

XML parsing performance

@Araq is there any reason we can't have `--opt:speed` for regular debug builds? Using the code from OP yields this: # DEBUG nim c -r g.nim # Time taken: 14.058434 Run # DEBUG with --opt:speed nim c -r --opt:speed g.nim # Time taken: 3.76424

XML parsing performance

On its own line character cells aren't so expensive that both is very chatty. I had mentioned `SLOW, DEBUG MODE` which might be better spelled `***SLOW, DEBUG MODE; See manual/etc.***`..

XML parsing performance

Coloring the word "Debug" helps, however, maybe we need a better term. "SLOW"? Any better ideas?

XML parsing performance

Thanks, @GamzWithJamz. Color certainly can make things pop, and I've also personally spent quite a bit of [time](https://github.com/c-blake/lc) [tweaking](https://github.com/c-blake/procs) [colors](https://github.com/c-blake/hldiff) and have some generic support for run-time colors in [cligen](

XML parsing performance

I really appreciate the sort of "banner" feeling I get from that line. It contains a bunch of information important for the whole compile, but in a very visible manner. The current hint line is very hard to notice, especially if you configure file watches that trigger nim compilations. My termin

XML parsing performance

XML parsing performance

> Is there a list of checks anywhere with information about what the different > build modes enables/disables? You can read config/nim.cfg, it contains: @if danger or quick: obj_checks:off field_checks:off range_checks:off bound_checks:off overflow_chec

XML parsing performance

> that message should be the last thing you see when you compile; it should > stand out I agree being the last line of all the various output is another way to make sure people read it. However, it actually is already either the last or very close to the last. :-) I think it is really worth a

XML parsing performance

Is there a list of checks anywhere with information about what the different build modes enables/disables?

XML parsing performance

I understand that embedded environments are constrained. But, nowadays, this is more for an economical reason than for a technical reason. More memory means that each unit costs more and when you want to sell millions of units, this is indeed something to take in consideration. But this positio

XML parsing performance

> -d:danger shrinks the entire binary to approx 10Kb. I will soon write a > little bit about it Please do that, yes. However, one can also try with `--checks:off --indexChecks:on`. Integer overflows by themselves do not cause buffer overflows.

XML parsing performance

-d:danger is essential for embedded environments. newlib nano with nim is around 30Kb in release-mode (arm target, default toolchain - nim gc arc ). -d:danger shrinks the entire code to approx 10Kb. I will soon write a little bit about it|

XML parsing performance

The problem with the debug mode is that, for people who never used languages compiling to native code, it doesn’t explicitly states that in this mode programs will be considerably slower. Many will think that the program will be bigger (containing debugging data) which is true indeed, but will n

XML parsing performance

> the fact that there are 3 modes is a little confusing gcc has >500 compiler flags

XML parsing performance

`-d:release` is a good default, good performance, no compromises on safety. `-d:danger` is for the people who know what they are doing. It makes no sense to make `danger` the new default, I hardly ever use it myself fwiw. It's a terrible performance/safety tradeoff. Our goal should be to ensure

XML parsing performance

If we are going to rely on a message to help people get the most performance from their builds, that message should be the last thing you see when you compile; it should stand out (make it its own message, use a different color, etc.); and it should tell you something like "use -d:danger for max

XML parsing performance

`-d:release` takes longer time to compile as it try to optimize code, isn't it? I spend most of time with repeating changing code/compile/test. So I think build mode that takes shortest time to compile should be default. @cblake MS VC, cmake and meson also default to debug build.

XML parsing performance

I also think it's the difference between having a solid background in compiled languages like C/C++ etc. and interpreted ones like python/ruby etc.

XML parsing performance

Well, it's up to you. FWIW, both `gcc` and `clang` default to `-O0`. Not sure about MS VC, `go`, `rust`, `zig`, etc., but it would be unsurprising if 95+% of compiled languages defaulted to debug builds. "Make it correct first then fast" is even a mantra. Beginners do make this mistake, but not

XML parsing performance

A subtle hint would be to make the output if the output is not specified `program_debug.ext`.

XML parsing performance

I'm beginning to think that `-d:release` should simply be the default and then when a runtime crash is encountered it should say "compile with -d:debug to get a meaningful stack trace".

XML parsing performance

This does come up a lot, last I recall because [nimble build suppressed the messages](https://forum.nim-lang.org/t/7426). So, it would not matter what the message said. Not sure if this is fixed in nimble by now. All caps `DEBUG BUILD` may be warranted here to make it stand out. Maybe `RELEASE

XML parsing performance

If I'm allowed to throw in my 5 cent into the discussion I think we should have a pinned FAQ forum thread with the title "FAQ - Read this before posting!" or something along those lines. And the top entry should of course be `--d:release` vs `--d:debug`. That way we can get their attention when

XML parsing performance

It already says "Debug build", nobody reads it. The basic tutorials also mention `-d:release`.

XML parsing performance

@Araq this comes up very often lately, maybe a compile time hint ala: "for a release build compile with '-d:release' would be a good idea.

XML parsing performance

FWIW, for me doofenstein's version ran in 1.24 seconds on an 11 year old laptop on Linux on your input and a gcc-10.3 PGO build ran in 1.05 seconds (with the data you linked to in your thread-opening post). On more modern server HW it ran in 0.4 seconds. So, chances are high that if it's still

XML parsing performance

You're a gentle community with rookies... I like it. :)

XML parsing performance

what can help as well is putting the code into a function, so that the variables become local instead of global, which gives the compiler more optimisation opportunities, like so (I also changed some stylistic things :D): import streams, parsexml, times proc main() =

XML parsing performance

Thank you for your suggestions ynfle. Yeah, I probably should move to 1.4.6 and learn more about compile options.

XML parsing performance

`-d:danger` takes away bound checks and other safety mechanisms see . You could use any of``-d:release -opt:speed -d:lto``. Also try changing the garbage collector to `--gc:arc` (though I'd suggest using the latest version of n

XML parsing performance

WOW! Fantastic !!! With -d:danger option the execution time of the posted code dropped to slightly more than 3 secs. If applied to the version using shallowCopy, even less, around 2 secs and something! Thank you SolitudeSF. P.S. I just hope that applying -d:danger did not modify the space-time c

XML parsing performance

-d:danger

XML parsing performance

Hi to all, I'm new to NIM, but for what I've seen so far, I like it a lot. I really hope NIM's community and NIM adoption will grow up. I was wondering if I could use NIM for some specific tasks I have to deal with, and one of these is (huge) XML files parsing. I've seen a bit the online documen