Quote:
Originally Posted by Bad_Bud
I thought the concept behind the fakemeta high was that the engine module eats up CPU time when it's doing nothing, whereas fakemeta does not. I haven't seen anyone do a profile with fakemeta running for long periods of time with the engine module disabled, versus engine running for long periods of time. In most profiles, I see the fakemeta being compared with the engine in the same plugin, which guarantees that the engine module is still running -- defeating the purpose of a comparison between engine and "pure fakemeta"; we've taken away the most preached aspect of the comparison: engine module uses CPU when it is not being used.
I'm not taking sides, because I'm not advanced enough of a scripter to really care, but I think these tests are less intuitive than they appear, and that if we are going to state things as solid facts with profiles, fair tests should be run.
|
The difference of that the engine uses cpu always instead of fakemeta that it does not. Can be explained with a simple and plain example.
In fakemeta if you need the prethink forward you will register it.
Whereas in engine you place it as a function client_PreThink(id).
The difference is that fakemeta if it does not have any forwards to call (no plugins have this forward registered) it does not bother to get the forward from the engine and call the plugins.
Where as engine sends the function call to all the plugins (it doesn't care if the plugins have the forward or nor).
That is the difference.
I think that the "fakemeta high" problem started from the things that people misunderstood, they thought that fakemeta will use cpu when it is asked to, that is what was making fakemeta > engine not the power of the module itself. Both modules are great, and work flawlessly, using one of them is good but using both of them will make it all more efficient.
And this tutorial advices you to use less module communications because these are the problems when we talk about CPU usage (efficiency).
__________________