How fast is creating instances of types?

BlitzMax Forums/BlitzMax Programming/How fast is creating instances of types?

Grey Alien(Posted 2008) [#1]
Specifically, say I have a type with say 10 fields (mixture of strings, ints and floats and types) and I don't specify any default values for my fields, like this:

Type foo
  Field1%
  Field2#
  Field3$
  Field4:AnotherType
End Type


I assume that Bmax will just allocate a memory block that is all zeros with a simple command, and thus the fields will be zeroed or null (in the case of strings/type pointers etc). This should be pretty quick right? Does anyone know if it ACTUALLY does this or if the data is left random (which is even faster).

So let's say I assign some default values to the fields instead:

Type foo
  Field1%=0
  Field2#=1
  Field3$="hello"
  Field4:AnotherType=null
End Type


Obviously I can't assign a type to Field4 because none exist yet (maybe I can but it would be stinky bad programming).

Anyway, I'm now assuming this would be slower as the BlitzMax type contructor will have to individually assign each value to each field.

HOWEVER, here's what I really want to know ... let's say I assign a default value of 0 or null to every field, will the constructor be intelligent and NOT individually assign zero to each field because it knows the memory that was allocated was zeroed already (this is an assumption which could be false, it may be full of random data)? Or will it be slower because it foolishly manually assigns zeros/nulls to already blank fields?

Anyone have any idea on this or done any tests?

I ask because it could make a different if you say make 100 particles each with 50 fields that are being individually initialised instead of block initialised with a zero mem copy...(yes I know I should have a particle pool of pre-created types, but I'm just theorising here...)


ImaginaryHuman(Posted 2008) [#2]
All you gotta do is create an instance of your first `foo` type and print the contents of the fields. That's a read-only operation on the field so should show whether the creation of the type set them to default values.


dmaz(Posted 2008) [#3]
blitz initializes variable declarations to 0 and null.


Grey Alien(Posted 2008) [#4]
blitz initializes variable declarations to 0 and null.
Yeah I thought I read that somewhere before, BUT does it init them with a blank mem write of 0s or does it do each field in turn AND is it slower if you declare a field with a default of 0 because it writes that value in again?


computercoder(Posted 2008) [#5]
You must be needing some speed optimizations I'm guessing. I'd suspect that it re-assigns when you set the defaults. My personal opinion is to take the slight speed hit (if any) and go on and declare and init the variables. In the end, you'll end up needing to set these variables again to another value anyways unless they are constants.


TomToad(Posted 2008) [#6]
I would think any speed difference would be negligible, considering all that happens when an object is created. Not only do the fields need to be initialized, but the New() method needs to be processed (even if your type doesn't have a New() method, the base Object type does), the reference needs to be added to the GC, etc...
I guess that tests could be run to figure it out

Just ran some tests of my own.
first run:

second run:

Third Run:


The first run defines nothing and leaves the compiler to use defaults. The second run sets everything to defualt values explicitly (0.0 and Null), the third run defines non default values and does a New TTest for the field in TTest2

results
First run:
2531
2505

Second Run:
2516
2545

Third run:
2666
4907

As you can see, there is not any huge difference in the times except when an embedded type is initialized to an actual type and not Null. And even then, it is proportionately double which is consistent of having to initialize two different types at once.


Grey Alien(Posted 2008) [#7]
Wow EXCELLENT test TomToad. Many thanks. From this I can see that setting them all to 0/null is fine (no real speed difference) and supplying a few non-zero defaults only makes a tiny difference. With the type, if it wasn't created then, it would have to be created later at some point with an overhead then instead (actually that's what I'd do in case the type was not always needed).

Thanks again.