Code Optimisation – Talk
Jump to navigation
Jump to search
No edit summary |
(Added comment how to handle Global Array System description and link about 3ms) |
||
| Line 31: | Line 31: | ||
Well to me it's a pretty good way having all "Global Variables" of a specific feature stored in 1 array instead of creating 3 - 5 and more "Global Variables" for the most feature. | : Well to me it's a pretty good way having all "Global Variables" of a specific feature stored in 1 array instead of creating 3 - 5 and more "Global Variables" for the most feature. | ||
: Of course it will need some practice for use and understand how it works. | |||
: Just thought i should share this with others so everybody knows a second way of how it can be made. | |||
: If you think it's not need then simply remove it from the page. | |||
: | |||
: Not a big problem at all. ;) --[[User:SNKMAN|SNKMAN]] 17:49, 9 August 2010 (CEST) | |||
:: It is good to have it explained, I agree. What I argue is that this is not the right place. | |||
:: The page says code optimization and to me the design is quite the contrary. | |||
:: So I'd suggest to move it to a new page and reference it for example. --[[User:Kju|Kju]] 07:04, 10 August 2010 (CEST) | |||
---- | |||
Anyway... I have a question about a point in this article: | Anyway... I have a question about a point in this article: | ||
| Line 45: | Line 48: | ||
I don't really get the point... When exactly is this 0.3ms delay needed? | I don't really get the point... When exactly is this 0.3ms delay needed? | ||
Only in scripts/functions which was executed after the mission was initialized and started? | Only in scripts/functions which was executed after the mission was initialized and started? | ||
Many | Many thanks and keep this page growing. :) --[[User:SNKMAN|SNKMAN]] 17:49, 9 August 2010 (CEST) | ||
: Anything started with execvm/spawn will be under the engine's script scheduler's powers. If it thinks your script takes too long to execute, it will pause it (to let other scripts have some CPU time as well) for a unspecified time (that 3/0.3/0.03ms is probably a guess, as it most likely depends on the FPS the machine is running). [[User:Shuko|Shuko]] 18:23, 9 August 2010 (CEST) | : Anything started with execvm/spawn will be under the engine's script scheduler's powers. If it thinks your script takes too long to execute, it will pause it (to let other scripts have some CPU time as well) for a unspecified time (that 3/0.3/0.03ms is probably a guess, as it most likely depends on the FPS the machine is running). [[User:Shuko|Shuko]] 18:23, 9 August 2010 (CEST) | ||
: See [http://rte.jonasscholz.de/blog/2009/09/22/new-to-arma-2-the-3ms-break New to ArmA 2: The "3ms-break"] --[[User:Kju|Kju]] 07:04, 10 August 2010 (CEST) | |||
Revision as of 06:04, 10 August 2010
This article is brilliant. Thank you --Doolittle 16:57, 28 April 2010 (CEST)
Agree. ;) Very good information about how to make things work better. --SNKMAN 22:51, 8 August 2010 (CEST)
I want to open a discussion, if the use of the Global Array System should be recommended here at all
or at least it needs the following points as comments to take into account when reading about it.
The system was originally developed to avoid the GV limit for savegames in OFP.
This is no longer a problem, so no longer an argument to use this design.
Here are a couple of points we gather that argue against the use of this design:
1. Memory use
- We cannot really judge if it takes less memory, as we do not know the implementation.
- A large array itself may even take more; especially if not all elements are set.
- You can't undefine not used variables easily.
2. Performance
- Multiple selects from a huge array is most likely slower than referencing global variables.
- You always have to work with this monster of array.
- And use "select" and "set" to modify it instead of simple variable assignment.
3. Code design
- The array design is hard to read and to understand.
- The lack of variable naming makes it even worse.
Anyone is welcome to comment this. Ty. --Kju 08:30, 9 August 2010 (CEST)
- Well to me it's a pretty good way having all "Global Variables" of a specific feature stored in 1 array instead of creating 3 - 5 and more "Global Variables" for the most feature.
- Of course it will need some practice for use and understand how it works.
- Just thought i should share this with others so everybody knows a second way of how it can be made.
- If you think it's not need then simply remove it from the page.
- Not a big problem at all. ;) --SNKMAN 17:49, 9 August 2010 (CEST)
- It is good to have it explained, I agree. What I argue is that this is not the right place.
- The page says code optimization and to me the design is quite the contrary.
- So I'd suggest to move it to a new page and reference it for example. --Kju 07:04, 10 August 2010 (CEST)
Anyway... I have a question about a point in this article: The "The 0.3ms delay" could anyone explain this a little bit more in detail please? I don't really get the point... When exactly is this 0.3ms delay needed? Only in scripts/functions which was executed after the mission was initialized and started? Many thanks and keep this page growing. :) --SNKMAN 17:49, 9 August 2010 (CEST)
- Anything started with execvm/spawn will be under the engine's script scheduler's powers. If it thinks your script takes too long to execute, it will pause it (to let other scripts have some CPU time as well) for a unspecified time (that 3/0.3/0.03ms is probably a guess, as it most likely depends on the FPS the machine is running). Shuko 18:23, 9 August 2010 (CEST)
- See New to ArmA 2: The "3ms-break" --Kju 07:04, 10 August 2010 (CEST)