NASM slow

[s4uri3r]

hi,

first sry for my bad english, i'm not a native speaker..
ok, the problem is, NASM gets slow anytime my projects get bigger. OK, it's ordinary, but I think, it's strange an assembler, who has "only" to translate the code, takes 10 secs time on a good pc for <4000 lines of code.. maybe there are known tactics to speed it up or is this normal?

regards,
s4uri3r

[alex136]

When your projects are big and you use variables, NASM does extra passes throught the source code.
This is time-consuming, specially if you have many files for one project.
Just see Dev-C++ when compiling a 'Hello world!' small program on my computer 6 seconds, while NASM does the equivalent in assembly in less than 1s.
But the output files have very different sizes for C and Asm. code.

[Frank Kotler]

Hi s4uri3r,

Nasm is not especially "fast", but 10 seconds for 4000 lines of code seems excessive. One of my recent projects runs about 2000 lines of code, and assembles in about 0.2 seconds (on a P4, 1.8GHz - a "not-so-good" computer) - but it doesn't "%include" any files, and uses few macros, either of which could slow Nasm down.

One obvious solution is to break your project down into multiple files, and use a makefile so that only the changed files are assembled each time - but you shouldn't "have" to do that. In some cases, it may help to do one "preprocess only" pass (nasm -f -e myfile.asm>myfile.pre), and then an "assemble only" pass (nasm -f -a -Ox myfile.pre). When Nasm does multiple passes, it starts with "preprocess" each time, normally, so avoiding that can help - if you're using the "-O" switch, and your file requires an unusually large number of passes to resolve jump displacements. Not a great solution, at best, and may not help at all...

There's the "have a cup of coffee" solution...

Ten seconds seems like "too much". Can you give us more information about exactly what you're doing? (Nasm version, command line, included files, etc.) Sorry I don't have a better answer.

Best,
Frank

[s4uri3r]

hi,

thanks for your help xD  it's unbelievable, but Frank Kotler your solution works (it's less than 2 seconds now) there's only one thing, i have a function to use a windows function and two "%if..." cause some trouble now:

Code: [Select]

       ;%if (%1<>0) && (%2 <> PeekMessageA) && (%2 <> GetMessageA) && (%2 <> DispatchMessageA) && (%2 <> TranslateMessage) && (%2 <> ShowWindow) && (%2 <> SetClassLongA) && (%2 <> SetCursor) && (%2 <> SetScrollInfo) && (%2 <> SendMessageA) && (%2 <> SetBkColor) && (%2 <> SetTextColor) && (%2 <> EnableWindow) && (%2 <> EnableMenuItem) && (%2 <> LB_GETSELITEMS)
           ;%if (%2 <> CreateFileA) && (%2 <> SetFilePointer) && (%2 <> FindFirstFileA)
           ;     cmp eax,0
           ;     jne %%C_fkt_next1
           ;%else
                cmp eax,4294967295
                jne %%C_fkt_next1
           ;%endif
           mov eax,%1,[win_structure+4],DWORD 0
           jmp C_fktfehler

           %%C_fkt_next1:
;%endifI commented the "%if.." out and maybe I can solve this in another way, but is there also a way, it works this way? (the error is: "symbol references not supported in preprocess-only mode")

regards,
s4uri3r

[Frank Kotler]

Oops! I forgot to mention that "preprocess only" mode doesn't handle "forward references" (since it's only making one pass). Sometimes you can work around this by making sure that your symbols are defined "first" (in source code order), but I can't get it to work here. Nasm is being fussier than I expected! Commenting out half your code is "not a solution".

Obviously, you've got "mov" defined as a macro - it won't assemble as-is. I ASSume it expands into two "mov"s(?). I can't imagine why anyone would want to do this, but... people do it, whether I can imagine why or not.

So "-e" isn't going to help you, I guess. That leaves "divide it up into multiple files", and "be patient". Ten seconds seems "painfully slow", but the easiest solution may be just to wait... Leaving off the "-O" switch (if you're using it) will limit Nasm to two passes - might help. "-O1" should enable the "signed byte" optimizations, but not do extra passes to optimize jump displacements - maybe an acceptable compromise?

Again, I'm sorry I don't have a better answer.

Best,
Frank

[s4uri3r]

hi,

Obviously, you've got "mov" defined as a macro - it won't assemble as-is. I ASSume it expands into two "mov"s(?). I can't imagine why anyone would want to do this, but... people do it, whether I can imagine why or not.

yeah, so i can write many following "mov"-commands in one line and it changes a "mov ...,0" in "xor ...,...", so it is an easy way to make the code much more easier and faster to read  you write "it won't assemble as-is", i tried it, and it assembles it the right way 

So "-e" isn't going to help you, I guess. That leaves "divide it up into multiple files", and "be patient". Ten seconds seems "painfully slow", but the easiest solution may be just to wait... Leaving off the "-O" switch (if you're using it) will limit Nasm to two passes - might help. "-O1" should enable the "signed byte" optimizations, but not do extra passes to optimize jump displacements - maybe an acceptable compromise?

but -e helps me much, and the "mov"-macro however works, there are only these two "%if" don't working, and with some changes I can work without them, so thank you for the suggestion 

regards,
s4uri3r

[Frank Kotler]

hi,

Obviously, you've got "mov" defined as a macro - it won't assemble as-is. I ASSume it expands into two "mov"s(?). I can't imagine why anyone would want to do this, but... people do it, whether I can imagine why or not.

yeah, so i can write many following "mov"-commands in one line and it changes a "mov ...,0" in "xor ...,...", so it is an easy way to make the code much more easier and faster to read 

Feed it to the rosebushes, it'll make 'em bloom!

Best,
Frank

[H. Peter Anvin]

One thing: the original poster didn't say what version of NASM he was using, but if he was using the 0.98.xx versions, he should upgrade to 2.0x; the 2.0x are *way* faster than the older ones, especially in preprocessor-heavy code.

[Cyrill Gorcunov]

I tempted to see the .asm listing which makes nasm slow. So if reported is able to post source code -- this would be extremely helpful

[H. Peter Anvin]

Very much so... this performance seems just off-the-chart bad.  In NASM 2.xx even my million-macro testcase runs in a few seconds.

[Rob Neff]

hmmmm....4-5 seconds average to process a current NASMX demo due to heavy preprocessing (down from ~6 seconds per demo due to elimination of macro to macro calls).

You may want try timing  http://sourceforge.net/projects/nasmx/

ps: I should add that the demos I'm refering to are the win32 ones...