www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - long compile time 2.023 (few lines of code)

reply "Saaa" <empty needmail.com> writes:
The following code takes too long to compile (I kill link.exe to stop it)
dmd 2.023 bud -full - cleanup

--
module project.main;

import project.bug;

void main()
{

}
--
module project.bug;

struct Struct
{
 uint number;
 int[6] array;
 byte[9] array2;
}
Struct structs[1_000_000];
--

Multiple variations on the struct seem to have the long compile time 
effect.. allignment problem?
Jan 23 2009
next sibling parent reply Denis Koroskin <2korden gmail.com> writes:
Saaa Wrote:


 The following code takes too long to compile (I kill link.exe to stop it)
 dmd 2.023 bud -full - cleanup
 
 --
 module project.main;
 
 import project.bug;
 
 void main()
 {
 
 }
 --
 module project.bug;
 
 struct Struct
 {
  uint number;
  int[6] array;
  byte[9] array2;
 }
 Struct structs[1_000_000];
 --
 
 Multiple variations on the struct seem to have the long compile time 
 effect.. allignment problem?
 
 


Slightly reduced test case that reproduces the same problem:

module bug;

struct Struct
{
uint number;
int[6] array;
byte[9] array2;
}
Struct structs[1_000_000];

void main() {}

FWIW, it gives me the following error message when compiled with D1.029 (might
help to debug):

Unexpected OPTLINK Termination at EIP=0040E0DE
EAX=00DC0000 (changes)
EBX=00431D10
ECX=00000A90
EDX=000008C2
ESI=845511F5
EDI=00DC15C0 (changes)
EBP=0012FFF0
ESP=0012FF58
First=00402000

D1.032+ just hang.

Worth putting into bugzilla, I think.
Jan 23 2009
parent "Saaa" <empty needmail.com> writes:
:) forgot to test it outside main.
Placing the struct inside main doesn't result to a problem.
<=915_045 no problem

=915_046 problems



 Slightly reduced test case that reproduces the same problem:

 module bug;

 struct Struct
 {
 uint number;
 int[6] array;
 byte[9] array2;
 }
 Struct structs[1_000_000];

 void main() {}

 FWIW, it gives me the following error message when compiled with D1.029 
 (might help to debug):

 Unexpected OPTLINK Termination at EIP=0040E0DE
 EAX=00DC0000 (changes)
 EBX=00431D10
 ECX=00000A90
 EDX=000008C2
 ESI=845511F5
 EDI=00DC15C0 (changes)
 EBP=0012FFF0
 ESP=0012FF58
 First=00402000

 D1.032+ just hang.

 Worth putting into bugzilla, I think.
Jan 23 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Saaa" wrote

 The following code takes too long to compile (I kill link.exe to stop it)
 dmd 2.023 bud -full - cleanup

 --
 module project.main;

 import project.bug;

 void main()
 {

 }
 --
 module project.bug;

 struct Struct
 {
 uint number;
 int[6] array;
 byte[9] array2;
 }
 Struct structs[1_000_000];
 --

 Multiple variations on the struct seem to have the long compile time 
 effect.. allignment problem?


allocating 40MB of static data seems a bit excessive.

1. Your exectuable is probably going to be 40MB (not sure)
2. allocating on the heap is probably going to be faster than this, as the 
OS would not have to read 40MB of static data from the disk.

Is there a reason why you want to do it this way instead of:

Struct[] structs;
static this
{
   structs = new Struct[1_000_000];
}

-Steve
Jan 23 2009
parent "Saaa" <empty needmail.com> writes:
 allocating 40MB of static data seems a bit excessive.

 1. Your exectuable is probably going to be 40MB (not sure)
 2. allocating on the heap is probably going to be faster than this, as the 
 OS would not have to read 40MB of static data from the disk.

 Is there a reason why you want to do it this way instead of:

 Struct[] structs;
 static this
 {
   structs = new Struct[1_000_000];
 }

 -Steve


My executable is only 177KB
Jan 23 2009
prev sibling parent reply torhu <no spam.invalid> writes:
On 23.01.2009 18:49, Saaa wrote:

 The following code takes too long to compile (I kill link.exe to stop it)
 dmd 2.023 bud -full - cleanup

 --
 module project.main;

 import project.bug;

 void main()
 {

 }
 --
 module project.bug;

 struct Struct
 {
   uint number;
   int[6] array;
   byte[9] array2;
 }
 Struct structs[1_000_000];
 --

 Multiple variations on the struct seem to have the long compile time
 effect.. allignment problem?


 From http://www.digitalmars.com/d/1.0/arrays.html :

"The total size of a static array cannot exceed 16Mb. A dynamic array 
should be used instead for such large arrays."

It's an optlink limitation, so it's not likely to get fixed either.
Jan 23 2009
parent reply "Saaa" <empty needmail.com> writes:
Lol I didn't even check that.
Probably because it does compile (and gives a stack overflow at runtime) 
when you put the allocation within the main.
So it still looks like a bug. The compiling should not hang.


 From http://www.digitalmars.com/d/1.0/arrays.html :

 "The total size of a static array cannot exceed 16Mb. A dynamic array 
 should be used instead for such large arrays."

 It's an optlink limitation, so it's not likely to get fixed either.
Jan 24 2009
parent reply "Saaa" <empty needmail.com> writes:
Should I report this as a bug?
And, how do I do that :)



 Lol I didn't even check that.
 Probably because it does compile (and gives a stack overflow at runtime) 
 when you put the allocation within the main.
 So it still looks like a bug. The compiling should not hang.


 From http://www.digitalmars.com/d/1.0/arrays.html :

 "The total size of a static array cannot exceed 16Mb. A dynamic array 
 should be used instead for such large arrays."

 It's an optlink limitation, so it's not likely to get fixed either.
Jan 26 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 27 Jan 2009 01:08:17 +0300, Saaa <empty needmail.com> wrote:


 Should I report this as a bug?
 And, how do I do that :)



 Lol I didn't even check that.
 Probably because it does compile (and gives a stack overflow at runtime)
 when you put the allocation within the main.
 So it still looks like a bug. The compiling should not hang.


 From http://www.digitalmars.com/d/1.0/arrays.html :

 "The total size of a static array cannot exceed 16Mb. A dynamic array
 should be used instead for such large arrays."

 It's an optlink limitation, so it's not likely to get fixed either.






I fill bugreports at http://d.puremagic.com/issues/

But not for this one, as it won't be fixed because of the said reason.
Jan 26 2009
next sibling parent "Saaa" <empty needmail.com> writes:
But why does enclosing the allocation within the main change the way the 
array is handled?
outside main = hang
inside main = correct compile  +  runtime error


 I fill bugreports at http://d.puremagic.com/issues/

 But not for this one, as it won't be fixed because of the said reason.
Jan 26 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:

 But not for this one, as it won't be fixed because of the said reason.


The limit of the linker may not be solved, but I think it's good to add an
error message to the compiler for such situation, so the compiler stops
compilation immediately with a clean error message and the programmer knows
what's wrong with the code and can fix it.

(LDC compiler may not have such limit, so such error message may be useless for
LDC).

Bye,
bearophile
Jan 26 2009