I have a program with a .DATA? section like this:


apoint struct
xpos word ?
ypos word ?
color dword ?
apoint ends

pts apoint 100000 dup({?,?,?})

Everything works fine, except that when assembling this 100,000 element array, ML takes about 20 seconds on my 500 mhz computer. Interestingly enough, when i switch ML out of /coff mode, the program compiles almost instantaneously, but then LINK can't make the .obj file into a PE executable. Why does ML take so long? How can i speed it up? I intend to up the array size to 1,000,000 but dont want to wait 200 seconds for my program to compile.

Posted on 2002-02-11 17:05:10 by LOLTH
I have had the same problem. If I still had SI installed I'd take a look to see what MASM is doing for a couple minutes of my time - this is unacceptable! Serious bug here, IMO.
Posted on 2002-02-11 17:15:03 by bitRAKE

Yes, that's an annoying feature of Masm. What I do is to create a separate module with your array in it and then just assemble it once. Use EXTERN in the main module. Then link them together and it's done. Don't forget to make your array PUBLIC. Hope it helps.

Posted on 2002-02-11 17:27:09 by Salieri
Or you could dynamically allocate the memory at run time....
Posted on 2002-02-11 17:38:49 by sluggy
I agree with Sluggy here, far better solution in code design and it should build faster as well.


Posted on 2002-02-11 19:16:32 by hutch--
Can someone give me a refresher course on that :) dynamically allocate arrays that is...

Or a link will be fine too :-) I wish I had a 32 bit assembler book (*hint* *hint* *wink*wink*), like the one I use for C++. I could then just open it to the "dynamically created arrays" capter and not bother you fine folks.


Ok I'm the worlds bigest ass... Maybe I should do a search first and then post the question later:

Posted on 2002-02-11 22:44:14 by Sliver
Not really the worlds biggest, Sliver. In your defense: you honestly label yourself to help protect those unfamiliar with you, and more importantly you post the said found link here for others (which serves to prove the affore mentioned point :)). Lesser men would cowardly let others do the work and post replies - all the while having the resources to solve his problem. So, that makes you a productive member of the community. :alright:
Posted on 2002-02-11 23:03:56 by bitRAKE
Damn, i could have used that lib 6 months ago.... i ended up writing my own, it's a pain when you have to do the work yourself :rolleyes: :)

LOLTH: here is another option: use a linked list. There are some cases where this may be preferable to an array.
Posted on 2002-02-11 23:56:22 by sluggy
Originally posted by bitRAKE
Not really the worlds biggest, Sliver

Thanks Bitrake :) I really appreciate that...

Although it still would have been smarter to do the search first :)


ps. I have to say that so I can come down hard on those who don't do this in the future :) :) :)

After taking a good look at Eoin's example I kinda wonder how C++ compilers hande he allocations for a dynamic arrays?
Posted on 2002-02-12 02:02:42 by Sliver
Big allocations, ho humm... if you need dynamic stuff, look at Eo?n's
dynamic array stuff. Or HeapAlloc/HeapRealloc if you want to try
to make your own stuff. If you just need one huge old array that
will never be resized, VirtualAlloc is the way to go (4k aligned, size
rounded to 4k). Both Heap* and VirtualAlloc zeroes the memory blocks.
Posted on 2002-02-12 09:40:30 by f0dder
OK, Thanks!

I will go with dynamic allocation.
I am writing a program which graphs a search space of different algorithms based on their fitness at solving a given problem. The graph is an array of points on the screen, each with a different color, representing different fitnesses. As you all know there are large numbers of points on a screen and so I have to have a large array to hold all those points.
Is there a big difference in the speed of VirtualAlloc and HeapAlloc? Ideally I could allocate different amounts of memory for different graph sizes, but if HeapAlloc is really slow I may as well just VirtualAlloc the maximum amount of memory needed once.

Thanks again.
Posted on 2002-02-12 15:32:07 by LOLTH
Both Heap* and VirtualAlloc zeroes the memory blocks

Then is HEAP_ZERO_MEMORY (for HeapAlloc) useless ?

According to the Platform SDK November 2001 Edition :
HEAP_ZERO_MEMORY : Specifies that the allocated memory will be initialized to zero. Otherwise, the memory is not initialized to zero.

Posted on 2002-02-12 15:38:17 by JCP
The thing is not about whether to use or not dynamically allocated
The thing is that MASM work slooooooooow with big data.
I have a lot of cases in my programming when:
1. You can not solve your problems using allocated arrays -
'cause it is special big tables of some system data and it sould be
initialised (of course I can write some code that would fill this tables but the code it self will take almost the same size as data)
2. I use case calculations (especially with coding\decoding well
cripted data) and if some data not in predrfined places it would take ~1000 times more to complete the job.

So it is big minus of MASM.
I like MASM, the only worthy proof of it - I use it as main instrument in my work. And I'm ready to close my eyes on all
other things in MASM.
But working with large piece of data in MASM is painfull headake.
It is not a problem only for those who never had a task that needs big chunk of predefined data.
Posted on 2002-02-12 16:03:11 by The Svin
The graph is an array of points on the screen, each with a different color, representing different fitnesses.

Here is another brilliant idea from left-field: use a bitmap to directly store the graph points. You would need to write a quick algo that would translate array positioning to/from a certain pixel, but that should not be hard. After all, your graph stored in memory is going to end up as a picture anyway, isn't it? Or are you going to send the data to some other 3rd party app?
Another advantage to using a bitmap to store your data is that there are already some APIs for dealing with them (i.e. saving/loading), that will save you some work.

Now, lets see what comments this generates :)
Posted on 2002-02-12 16:52:35 by sluggy
Svin, I've made a tool to convert binary data to linkable coff .obj,
perhaps that would be of use to you? I can post it here (again ;))
one of the following days, after I clean up the source a bit.
Posted on 2002-02-13 12:47:31 by f0dder
Ok, now im *really* confused.

How is MASM to be the fault of slow access for predefined data, when all it does is properly builds the PE header entries, and copys the data to a location in the final exe???

To me it sounds like its the PE thats the problem... Which raises the questions, how does other compilers make this process "faster"... To me the code sound be the same regardless, as well as the binary data packed into the exe...

I *really* think im missing something here...
Posted on 2002-02-13 13:45:48 by NaN
So, I guess I'm not the only one here experiencing this problem.

use TASM :) . assembles faster than MASM he! he! he! (here's umberg6007 again on his quest on promoting TASM :grin: )
Posted on 2002-02-13 14:07:24 by stryker
to umberg6007:
Yes, TASM is faster in such a case.
I just get used to MASM.
to f0dder:
Thank you.
I would love to try it.
Posted on 2002-02-13 14:41:54 by The Svin

The idea of using a bitmap to store the graph is an excellent idea. It will use less space and be far faster to display. I will get to work on doing that as soon as i have a valid graph to display and as soon as i learn how to deal with bitmaps ;) .
Posted on 2002-02-13 19:21:44 by LOLTH
The idea of using a bitmap to store the graph is an excellent idea.

Glad you like the idea. Just be aware that with the bitmap, you can only have one value in any particular pixel position, but then again you would have the same problem with using a standard array, you will just need to work out a rule for any values that collide like this.
Posted on 2002-02-13 21:04:00 by sluggy