ID:1231466
 Apr 8 2013, 3:56 pm
|
|
I'm pretty sure it is expensive to Del and Create new mob/atoms. Would it be wise to use the MOVE proc to simulate death instead of the DEL function. How much processing power is saved if this is faster?
| |
If you're sure that you have cleared all references to the mob, changing the loc to null would be okay. If you're not sure, deleting them is the way to go because it says you that kind of headache. I agree with Albro on this one though. Unless you're creating an deleting a lot using del is okay and should have little impact on performance.
| |
Generally speaking, I don't invoke the del command except in certain cases, like ending spawn() processing explicitly.
I wrote a helper for this a while back, that keeps track of dereferenced instances of objects and pops them into a queue. Then, whenever I want to instantiate a copy of the mob, I tend to just call out to the pool handler to check the list for references of type, then return if found. Otherwise, it just returns a new object of type. I'd like to expand this system to handle variable pool sizes and variable inactivity timeouts, but for the most part, the system is overkill for your average purpose. I usually try to create objects in global pools first, client pools second, and instance pools last. If something can't be acheived by a global pool, I do a client pool. If something can't be acheived by a client pool, I go for an instance pool. Generally speaking, though, most everything can be handled with global pools and there is no need for per-instance object pools. | |
I'd have to ask "What performance issue are you seeing now, that warrants asking this?".
When discussing optimisation, you essentially have two categories of problem:
Although they may share some solutions, you treat these two cases quite differently in terms of your approach and importantly, when you consider them. By way of example: Inherent need for optimisation These are cases you can identify in advance of programming. For BYOND games I think, these are actually somewhat rare. Real-world examples from my work have included:
One thing you'll notice immediately, is all of my examples have been quantified and they are specific. They've not necessarily been quantified with any serious accuracy, but the order of magnitude shown is correct. Without quantification, it is very difficult for you to decide if something needs optimisation in advance or not. That means either I or a fellow engineer sat down for 10 minutes at some point, and collected some data to help us work out just how "big" the problem might be. Once identified, you can start to optimise. Implementation specific need for optimisation These are where you've written code, tested it, and seen it's slow or laggy. This actually represents the majority of where you spend your time optimising /and that is okay and expected/. These are actually very nice to optimise, because you have a working system, you can see the problem and you can see the effect your changes has. Not to mention, with the profiler, you can collect data easily. --- The former, are Design Philosophy questions. They are rarer, take more time to assess and discuss etc. The latter, are Developer Help questions. They are more common, quicker to collect data for etc. For your question ... it sounds like it's the latter, because a question that vague (and unquantified) cannot really be the former. Given that, I'd be tempted to agree with Albro1 and say "This just doesn't matter", that it's a question that in all probability, doesn't warrant a technical answer. If you have a specific, implementation issue, then lets discuss that. Otherwise, lets not pre-optimise something and add complexity to something that in all probability ... won't affect your game's overall performance as seen by real world users. | |
And at risk of recycling what I say ...
http://www.byond.com/members/ Giacomand?command=view_post&post=1108928&hl=del&hla=Stephen0 01#comment3816488 That covers the debate on del() versus null referencing. Basically I'd expect you'd avoid using del() 99% of the time out of principle, because aside from the performance concerns you have an issue of pulling out null references in variables where you'd really not anticipated doing so. | |
I mostly wanted to know which was more efficient. For example in a castle type game. If all the mobs where created on startup and held somewhere on the map. Then when these mobs are needed the location would simply change and vice versa when they were killed. Versus, simply creating the mobs at runtime/ deleting them. I know for languages like Java creating objects are expensive. I just wanted to see if byond was similar.
| |
Actually, object creation in Java is super cheap, you can usually make of the order of millions of objects per second, probably tens of millions of objects per second if they are simple in nature. Similarly, Java operates internal pools.
BYOND is (for your purposes) the same. A castle game for example probably shouldn't be creating enough objects to warrant actively recycling. | |
Stephen001 wrote:
Actually, object creation in Java is super cheap, you can usually make of the order of millions of objects per second, probably tens of millions of objects per second if they are simple in nature. Similarly, Java operates internal pools. Except, we neglect to talk about how byond communicates changes on the server to the clients. It's my understanding that only graphical and locational changes are sent to the client, so deleting objects repeatedly is going to communicate a larger amount of data to the clients than simply relocating an object. Of course, that just might be theoretical. | |
If it's appearance changes, it needs communicating. Being taken off map would also count as such. As it is, you don't thrash that many viewable objects.
| |
In most cases I would probably move them somewhere inaccessible. However, as far as power saving goes, as long as you don't have a butt-load of mobs that you are creating/deleting over and over again, it shouldn't really make a noticeable impact.