Ok, so I am working along on cleaning up a little fubar that I had in one of my include files (failed to remove some ; from struct / union names... Duh) and next thing I know is that when remove the offending ;'s from the below struct definition my compile times start to get very very very very slow and I was just wondering if anyone else out there has ran into this?

Seems to me that either I have done something stupid (which would not be the first time, just ask my wife:grin: or there is a bug in ML).

Btw as a side note if I reduce the number of named nested structures by turning them into unamed structres then the compile time starts to speed up.

MajorFunction BYTE ? ;+000h
MinorFunction BYTE ? ;+001h
Flags BYTE ? ;+002h
Control BYTE ? ;+003h

UNION Parameters

STRUCT _Create
SecurityContext pIO_SECURITY_CONTEXT ? ;+004h
Options DWORD ? ;+008h
FileAttributes WORD ? ;+00Ch
ShareAccess WORD ? ;+00Eh
EaLength DWORD ? ;+010h
ENDS ; _Create

STRUCT _CreatePipe
cpSecurityContext pIO_SECURITY_CONTEXT ? ;+004h
cpOptions DWORD ? ;+008h
cpReserved WORD ? ;+00Ch
cpShareAccess WORD ? ;+00Eh
ENDS ; _CreatePipe

STRUCT _CreateMailslot
cmSecurityContext pIO_SECURITY_CONTEXT ? ;+004h
cmOptions DWORD ? ;+008h
cmReserved WORD ? ;+00Ch
cmShareAccess WORD ? ;+00Eh
ENDS ; _CreateMailslot

rLength DWORD ? ;+004h
rKey DWORD ? ;+008h
rByteOffset LARGE_INT <> ;+00Ch
ENDS ; _Read

wLength DWORD ? ;+004h
wKey DWORD ? ;+008h
wByteOffset LARGE_INT <> ;+00Ch
ENDS ; _Write

STRUCT _QueryDirectory
qdLength DWORD ? ;+004h
FileName pSTRING ? ;+008h
FileInformationClass DWORD ? ;+00Ch
FileIndex DWORD ? ;+010h
ENDS ; _QueryDirectory

STRUCT _NotifyDirectory
ndLength DWORD ? ;+004h
CompletionFilter DWORD ? ;+008h
ENDS ; _NotifyDirectory

STRUCT _QueryFile
qfLength DWORD ? ;+004h
qfFileInformationClass DWORD ? ;+008h
ENDS ; _QueryFile

sfLength DWORD ? ;+004h
sfFileInformationClass DWORD ? ;+008h
FileObject pFILE_OBJECT ? ;+00Ch

ReplaceIfExists BYTE ? ;+010h
AdvanceOnly BYTE ? ;+011h

ClusterCount DWORD ? ;+010h
DeleteHandle pVOID ? ;+010h


ENDS ; _SetFile

qeLength DWORD ? ;+004h
EaList pVOID ? ;+008h
EaListLength DWORD ? ;+00Ch
EaIndex DWORD ? ;+010h
ENDS ; _QueryEa

seLength DWORD ? ;+004h
ENDS ; _SetEa

STRUCT _QueryVolume
qvLength DWORD ? ;+004h
FsInformationClass DWORD ? ;+008h
ENDS ; _QueryVolume

STRUCT _SetVolume
svLength DWORD ? ;+004h
svFsInformationClass DWORD ? ;+008h
ENDS ; _SetVolume

STRUCT _FileSystemControl
OutputBufferLength DWORD ? ;+004h
InputBufferLength DWORD ? ;+008h
FsControlCode DWORD ? ;+00Ch
Type3InputBuffer pVOID ? ;+010h
ENDS ; _FileSystemControl

STRUCT _LockControl
lcLength pLARGE_INT ? ;+004h
lcKey DWORD ? ;+008h
lcByteOffset LARGE_INT <> ;+010h
ENDS ; _LockControl

STRUCT _DeviceIoControl
dicOutputBufferLength DWORD ? ;+004h
dicInputBufferLength DWORD ? ;+008h
dicIoControlCode DWORD ? ;+00Ch
dicType3InputBuffer pVOID ? ;+010h
ENDS ; _DeviceIoControl

STRUCT _QuerySecurity
SecurityInformation DWORD ? ;+004h
qsLength DWORD ? ;+008h
ENDS ; _QuerySecurity

STRUCT _SetSecurity
ssSecurityInformation DWORD ? ;+004h
ssSecurityDescriptor pVOID ? ;+008h
ENDS ; _SetSecurity

STRUCT _MountVolume
Vpb pVPB ? ;+004h
DeviceObject pDEVICE_OBJECT ? ;+008h
ENDS ; _MountVolume

STRUCT _VerifyVolume
vvVpb pVPB ? ;+004h
vvDeviceObject pDEVICE_OBJECT ? ;+008h
ENDS ; _VerifyVolume

Srb DWORD ? ;+004h
ENDS ; _Scsi

STRUCT _QueryQuota
qqLength DWORD ? ;+004h
StartSid pVOID ? ;+008h
SidListLength DWORD ? ;+010h
ENDS ; _QueryQuota

STRUCT _SetQuota
sqLength DWORD ? ;+004h
ENDS ; _SetQuota

STRUCT _QueryDeviceRelations
qdrType DWORD ? ;+004h
ENDS ; _QueryDeviceRelations

STRUCT _QueryInterface
InterfaceType pGUID ? ;+004h
qiSize WORD ? ;+008h
_Version WORD ? ;+00Ah
Interface pINTERFACE ? ;+00Ch
InterfaceSpecificData pVOID ? ;+010h
ENDS ; _QueryInterface

STRUCT _DeviceCapabilities
Capabilities pDEVICE_CAPABILITIES ? ;+004h
ENDS ; _DeviceCapabilities

STRUCT _FilterResourceRequirements
IoResourceRequirementList pIO_RESOURCE_REQUIREMENTS_LIST ?;+004h
ENDS ; _FilterResourceRequirements

STRUCT _ReadWriteConfig
WhichSpace DWORD ? ;+004h
Buffer pVOID ? ;+008h
rwcOffset DWORD ? ;+00Ch
rwcLength DWORD ? ;+010h
ENDS ; _ReadWriteConfig

slLock BYTE ? ;+004h
ENDS ; _SetLock

IdType DWORD ? ;+004h
ENDS ; _QueryId

STRUCT _QueryDeviceText
DeviceTextType DWORD ? ;+004h
LocaleId DWORD ? ;+008h
ENDS ; _QueryDeviceText

STRUCT _UsageNotification
InPath BYTE ? ;+004h
_Reserved BYTE 3 DUP (?) ;+005h
unType DWORD ? ;+008h
ENDS ; _UsageNotification

STRUCT _WaitWake
PowerState DWORD ? ;+004h
ENDS ; _WaitWake

STRUCT _PowerSequence
PowerSequence pPOWER_SEQUENCE ? ;+004h
ENDS ; _PowerSequence

SystemContext DWORD ? ;+004h
pType DWORD ? ;+008h
State POWER_STATE <> ;+00Ch
ShutdownType DWORD ? ;+010h
ENDS ; _Power

STRUCT _StartDevice
AllocatedResources pCM_RESOURCE_LIST ? ;+004h
AllocatedResourcesTranslated pCM_RESOURCE_LIST ? ;+008h
ENDS ; _StartDevice

ProviderId DWORD ? ;+004h
DataPath pVOID ? ;+008h
BufferSize DWORD ? ;+00Ch
wmiBuffer pVOID ? ;+010h

STRUCT _Others
Argument1 pVOID ? ;+004h
Argument2 pVOID ? ;+008h
Argument3 pVOID ? ;+00Ch
Argument4 pVOID ? ;+010h
ENDS ; _Others


islDeviceObject pDEVICE_OBJECT ? ;+014h
islFileObject pFILE_OBJECT ? ;+018h
CompletionRoutine pFunction ? ;+01Ch
Context pVOID ? ;+020h
Posted on 2003-01-09 14:50:16 by madprgmr


In assembler we have very few types of data, as you well know: byte, word, dword, and pointers, wich are the same ones, but treated differently.

I think this would only be usefull to you if it is really the labels that are slowing down your compiling time. ;)

Since your project seems to be very big, you need many structures.

Posted on 2003-01-09 15:18:09 by wicr0s0ft

I don't know if this is actually a problem, but my MASM Reference says:

Syntax: name STRUCT [, NONUNIQUE]
name ENDS

You seem to use something else..
Posted on 2003-01-09 15:41:28 by Guerrilla

I have seen the situation where large amounts of data in the uninitialised data section makes ML slow but the quantity of data you have in the structures and unions probably does not ad up to all that much.

Where I have tried it the data usually has to be over 200k or so before it really starts to slow things down.


Posted on 2003-01-09 17:08:31 by hutch--
Are you trying to define an array of IO_STACK_LOCATION structures?

MASM (in COFF mode) is known to be slow in creating large arrays -- even if doesn't contain any data! One possibility is to assemble in OMF mode, and then let the linker automatically invoke the OMF->COFF converter.

It would also be nice if you could simply say

ORG $+arraysize ; skip arraysize bytes

to allocate it quickly.

And since you cannot use any of the Win32 Alloc functions in a driver, you may want to use the kernel allocator functions: ExAllocatePool and ExFreePool. The extra headache is that you must ensure the pool is freed when needed under any (including error) conditions, as there is no background system to recover from memory leaks.

If you want to avoid the headaches and allocate statically, and the assembly time is too annoying -- put the array in a separate ASM module and use externdef (?) to link it to the other ASM code. You'll only need to recreate the array when you change the number of entries (assuming the size of IO_STACK_LOCATION is correct).
Posted on 2003-01-09 17:46:23 by tenkey