a quickey about TypeFields vs Local variables
Blitz3D Forums/Blitz3D Beginners Area/a quickey about TypeFields vs Local variables
| ||
| I have the habit of transfering the fields of types to local variables , when I use them more then once in a function. So: var1=type\field1 var2=type\field2 var3=var1*var2 : etc. instead of: var3=type\field1*type\field2 : etc. In the assumption that a Local would be faster in calculations. (and it types faster) But putting something in a local also takes some time, so... What method is better? (in general) |
| ||
| I don't think it really makes a lot of difference. |
| ||
| Locals should be much faster as there's a fair amount of indirection involved with Types. I'm not sure about Blitz3D, but locals are also often stored in CPU registers and other optimized memory so they are usually faster than standard memory access. If you're only accessing a field a few times per function call, then it's probably not worth transferring it to a local. If you're accessing it more than a few times, then it may be worth transferring it. Try doing some time-tests to see what gives you the best results. |
| ||
| I just did some tests :P it seems that just using locals is 4-times faster than just fields. and even taking in account the transfering of fields to locals first, its still more than twice as fast. (well as far as a fps-test means anything(cache etc.)) ---------------------------------- tes=typ\j\qwerty+typ\a+typ\b+typ\c+typ\d+typ\e+typ\f+typ\g+typ\h+typ\i FPS:121 ---------------------------------- a=typ\a b=typ\b c=typ\c d=typ\d e=typ\e f=typ\f g=typ\g h=typ\h i=typ\i j=typ\j\qwerty tes=j+a+b+c+d+e+f+g+h+i FPS:340 --------------------------------- tes=j+a+b+c+d+e+f+g+h+i FPS:550 --------------------------------- |
| ||
| orry to hijack this and resurrect it, but something I've been wondering about, kinda related is when using Type objects, COnsider this simple situation below: Type MyType Field AField Field AnotherField EndType Function DoStuffToInstanceOfMyType(ThisInstance.MyType) Print Str(ThisInstance\AField) End Function Are ALL the fields of that instance automatically converted to locals for the compiler, or just any that may be actually used within the function scope? My gut instinct tells me yes, and this may be best for quickly being able to retrieve the field values, but if there's a lot of fiel;ds, and if these fields are themselves instances of other types with lots of fields, it can kinda add up... |
| ||
| Are ALL the fields of that instance automatically converted to locals for the compiler, or just any that may be actually used within the function scope? Neither. Blitz3D doesn't perform such optimisations (especially because in this case, it wouldn't be an optimisation at all). The above conversation is about doing it manually. |
| ||
| Not sure I quite understand you or you me, Yasha :) I know my post wasn't directly concerned with the original topic, it was semi-related, though in terms of the efficiency of BB when it comes to dealing with Types and their fields. Are you saying that in passing Types, the actual field values are used? That's optimal in itself, since there's no localisation and no duplication, right? |
| ||
| Type objects are structs passed by reference (if you know C). When passing a type object to a function, the actual parameter is a four-byte pointer. To get at a field, the pointer is dereferenced (i.e. go to the type object's memory location, plus the offset in bytes of the desired field). This happens every time a field is accessed or mutated: the only thing that was passed to the function as a local was the original parameter, which is equivalent in size to an integer. At no point are any of the object's fields "cached" in the function's local storage, as there are few instances where this would give an obvious benefit (and generally identifying situations like the above, where there would be a benefit, is quite an advanced optimisation). |
| ||
| Ah that makes sense! Thanks,m Yasha! |
   |