[Help Request] TLS / Object Structure

[schlumpf]

computers get faster every year...
but programmers fail to optimize their code and the programs get slower more and more and need more memory.
so we need even faster computers etc..

If they wouldn't, there is no need in any faster computer. Noone thought of 4 GB RAM in home computers 20 years ago. Programs worked anyway.

In times of hardware being cheap as hell (10€ct/GB HDD, **** you.) noone even thinks about optimizing. If you look on the demoscene, you will see that you can pack everything that much (and upack it in RAM ofc..) that you wont need those 10 GB of textures in modern games. Look at fr-041 (debris). Its 177 ****ing KB! Unpack it and you will see the power of compression.

(Yah, I'm getting off topic).

Point is: You're right. xD

You could write a lot of apps way more efficient with less memory etc. but just noone cares.

Like about those dieing people in Africa. (Its off-topic-day!)

[Cypher]

yeah if you want now your supercool HP bars updated with 60 FPS, you get into trouble when you dont cache

edit:


yes, its far from slow. is even damn ****ing slow

no, serious...
dereferencing one pointer vs. dereferencing up to some hundreds.
(imagine you are in dalaran)
that sums up. and if you are caching the object, you have to refresh
it on zone change/relog etc. if you dont - you will face problems and so on...

for the sake of object oriented, cool, feature-rich program languages many
people switch to C# or similar and forget even to use fast algorithms
or "simple" solutions to get smth working.

e.g. they scan all buffs to get "isMounted" status instead of reversing
the functions and seeing that this would need just one pointer dereference.

computers get faster every year...
but programmers fail to optimize their code and the programs get slower more and more and need more memory.
so we need even faster computers etc..

Did you even read my post? How do you propose to work with ALL of WoWs objects with just "one pointer".

Slow is a relative term, and only a tiny tiny fraction (if any) of any given piece of software is performance critical. Sweating over a handful of ms is stupid. Write your code, profile it, THEN perform any necessary optimisations.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -Knuth

Of course you also want to avoid premature pessimization (as in the buff example), but realistically, in the example we're working with now, the difference is negligible.

Sure if you ONLY need to work with the local player then use that pointer. But if that's the case your bot or hack probably sucks pretty hard and doesn't have a big enough responsibility for performance to matter that much anyway.

You're sweating tiny stuff. If you want tiny memory consumption then go write all your software in ASM. Good luck maintaining a readable and portable code base for any software that's more complex than a hello world application though.

Though between CPU pipelining, speculative execution, branch prediction, loop vectorizing, etc. you'd be hard-pressed to write algorithms that are as safe as their high-level counterparts but also faster. The compiler simply knows the CPU better than you do (go compile a math-based application with ICC).

The fact of the matter is though, unless you have some glaring inefficiency like using an O(n^2) algorithm when O(n) or O(1) is available and you're working with very large data sets, you're never going to notice the difference. There's more important things when writing software.

[g3gg0]

Did you even read my post?

oh dear.. how often i have read this here...
(to be honest - everytime when someone is not 100% your opinion)
yes, i read yours. did you read mine?


donald knuth's rule does not apply here. thats no premature optimiziation.
its more like "preventing ugly code".

but the programmer has to know whats better for him:
rescanning all objects in the objmgr list or use the wow-cached player object pointer.

the former requires him to handle zoning and disconnects on his own when he is not periodically scanning the whole list to prevent illegal memory access. maybe you and me we wont have any problem with that issue.
but people that scan all buffs to get mount status will most likely have and annoy this forum again how to solve this.
(i remember at least 2 threads with that problem)

latter is simpler and always provides the current player object without any need to rescan the object list.
also it saves you from comparing an uint64 in every object to detect the player GUID without any disadvantage on the other hand.

its just idiot-proof.

[Cypher]

oh dear.. how often i have read this here...
(to be honest - everytime when someone is not 100% your opinion)
yes, i read yours. did you read mine?


donald knuth's rule does not apply here. thats no premature optimiziation.
its more like "preventing ugly code".

but the programmer has to know whats better for him:
rescanning all objects in the objmgr list or use the wow-cached player object pointer.

the former requires him to handle zoning and disconnects on his own when he is not periodically scanning the whole list to prevent illegal memory access. maybe you and me we wont have any problem with that issue.
but people that scan all buffs to get mount status will most likely have and annoy this forum again how to solve this.
(i remember at least 2 threads with that problem)

latter is simpler and always provides the current player object without any need to rescan the object list.
also it saves you from comparing an uint64 in every object to detect the player GUID without any disadvantage on the other hand.

its just idiot-proof.

As I said, if you want access to ALL OF WOWS OBJECTS you're going to have to scan the list anyway.

"also it saves you from comparing an uint64 in every object to detect the player GUID without any disadvantage on the other hand."

Incorrect. You have to maintain yet another set of structures unnecessarily.

The int64 compares take so little CPU time that if you need to worry about it you're probably trying to run it on your toaster.

Any LUA call that need to access the local player's data does a full lookup. I'm sure if it was a huge performance hit it would've been optimised out by now in a game like WoW.

Heck, just BENCHMARK IT. You'll see that the performance gain is (in realistic terms) zero, whilst the amount of work you have to do across patches is decreased.

But hey, if you like doing work unnecessarily to save yourself 0.1 FPS then go for it.

P.S. It's only idiot-proof until they change the structure (which happens a LOT more regularly than changes in the structure of the object manager).

EDIT: Ah, I see you're another C# user. In that case, maybe the alleged slowness of the list iteration (which is mandatory in a decent bot anyway but w/e) is due to inefficient use of the IPC apis.