flat assembler 1.51 FASMW.ASM line 386:


same line in flat assembler 1.50:


Why such increase? Is it because of hash tree?

Yes.

Good response

I tried compiling with 4MB, and it compiled everything I tried fine (one I had to increase 8, but it was 8 with older fasm too). So why is default increase so much?

Sometimes our master is very prolific. I was waiting a detailed answer too

I have noted that fasm tried to allocate a big quantity of memory to use only a small fraction of it. Doing in that way saves the time of bound checking. I have no idea about the difference in time between a large allocation and a smaller one

(sorry if this is already supported in fasm, I haven't used it extensively yet - I skimmed through the documentation and system.inc, though).

What about being able to specify memory limits on the commandline? I would suggest something like the following...

*) if nothing is specified on the cmdline, allocate default amount of memory. Either a percentage, as now, or some sensible smallish default that'll handle average-size apps (for those few large ones, it's not too bad passing along some cmdline argument I guess).

*) If only one size is specified on cmdline, allocate a block this large, and determine the fasm-internal size as a percentage of this block (probably with minimum (and maxmium?) size).

*) and of course, being able to specify total memory block size + fasm-internal block size on cmdline.

Just a suggestion, and nothing that's important to me with the size of the stuff I'm doing in fasm, but it might be helpful to other people


Hmm, interesting question actually. On proper OSes, the difference in allocation speed should be very small, if you're using a relatively low-level allocation routine. If you use HeapAlloc with HEAP_ZERO_MEMORY you should be able to feel some speed difference with large allocs; (on NT), VirtualAlloc'ing 768MB (even with MEM_COMMIT) takes a fraction of a second - mem usage ~900kb, VM size ~768mb. The 'real' allocation work is done later on, on access.

Can't remember my tests on 9x though, but iirc at least when using Memory-Mapped Files there, page-file space is *always* allocated - perhaps large VirtualAlloc's are slow, too.

My confusion was that I thought hashes of identifiers are supposed to take less space than actual string titles? And if duplicate hash exist, you use full string title. No?