NASM Forum > Programming with NASM

NASM slow

(1/3) > >>

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  :o :o 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: ---       ;%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:
;%endif
--- End code ---
I 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

Navigation

[0] Message Index

[#] Next page