[Wilson [29th ID]]

Originally Posted by l4ulwtlln does the speed much that much of a difference?

You have to realise that programmers often have little to no social lives, and often simply need something to keep them occupied - We call it speed.

[l4ulwtlln]

lol i just realized how bad i wrote that sentence.

so does someone want to give an example of why speed is so much more important?

[M249-M4A1]

Originally Posted by l4ulwtlln lol i just realized how bad i wrote that sentence. so does someone want to give an example of why speed is so much more important?

How about a real life example:

Would you want to rush your dying son to the hospital by taking the fastest route (even if it means running red lights)? Or take your time to get there, like obey the speed limits, traffic signals, etc.

While both are important, speed is the more preferrable way to go. Memory usage shouldn't be entirely a problem, since most servers are better-than-decent

[Wilson [29th ID]]

While we appreciate the bloody analogy, I'd reckon rushing and ignoring the street signs and regulations would be equivelant to typing it as quickly as you can and not even indenting or thinking efficiently at all. The irony of this is that to make your plugin fast, you have to write it slower - and think about it more.

And hell yes, I'm debating symantics. Reference my last post for the reason why.

I'd say speed and efficiency is like using proper equipment, such as a vaccuum cleaner, to conduct an abortion, thus not damaging the female or the uteris. The alternative is just to jam a coat hanger up there and start poking flesh until it falls out.

[Twilight Suzuka]

How about just using the ACTUAL CASE, instead of making a lot of confusing and stupid analogies?

The CVAR structure is an enormous linked list, meaning that every time you use the normal syntax for getting CVAR's, you have the potential to force the server to check every single CVAR. This is O(N) performance, or linear, and is absolutely terrible.

The server itself registers lots of CVAR's, other plugins register CVAR's, and your plugin registers CVAR's. This means that your one little call to find a CVAR's value could very well be hundreds of string comparisons and indirections (and usually is).

However, if you use the pointer syntax, you reduce this huge overhead to a single indirection, O(1) performance, which is the best performance possible, and worlds better than the other syntax.

You waste 1 cell of memory, 4 bytes, in order to reduce an operation which is potentially hundreds of string comparisons, hundreds of indirections, and millions of cycles, to a single indirection, perhaps a hundred cycles, less if it is in cache.

Save a million cycles, waste 4 bytes, make your code a little more complex.

This isn't about a memory / speed tradeoff. Trade off implies that there is some benefit either way over the other. There is absolutely no benefit to saving 4 bytes today, even on the smallest of microprocessors, if it means wasting potentially millions of cycles.

[l4ulwtlln]

now that you have pointed out that g[s]et_cvar has to cycle through many other cvars before it takes any action then i see what you mean now. thank you for your very informative answer