I would imagine your first scenario would run better, simply because in both instances you have the same amount of NPCs moving around, with less areas to download for the client.

However, to be more efficient, you should have the NPCs react and move around only when necessary - when say a player comes into view of them.

Alathon wrote:

"Why am I doing premature optimization?"

I'm not sure I'd call this an optimization. This sounds more like a design decision that might have performance implications. Putting some thought towards avoiding bad decisions is different than optimization.

As for the original question about performance: I'm not sure what the answer is. It sounds like you have a specific use in mind but it's not clear what that is. Put together a test case for each method and see how they perform.

Alathon wrote:

So he's trying to figure out the most optimal way to do something, before knowing if it makes a difference.

He suspects it might make a difference. If the rest of the program depends on this decision, taking time to consider what method is better is the smart thing to do.

Premature optimization is bad because it makes code messy and harder to work with. I understand how you could view this question as an optimization* but it doesn't have any of the risks that a premature optimization does. These methods are both simple and functionally equivalent, Tsfreaks is just wondering if there's a significant performance difference. Because you can never be certain of how BYOND will handle things it's very likely that two methods might seem equivalent but have drastic performance differences.

* If you think this is an optimization the act of writing code could be considered "premature optimization". Unless you're actively trying to write the most inefficient code possible you must be striving to achieve some level of efficiency. You have to think about the risks that come with an optimization. Replacing an insertion sort with a quicksort is often a no brainer - they're equivalent, quicksort tends to be more efficient, and it's a self-contained function so the change doesn't make a mess.

Edit: Reusing a variable within the same function can be bad because its name might not be appropriate for both uses and it makes the code harder to modify later. This is bad because it makes the code more confusing. The reason why you're told to avoid making optimizations like this is becauase the benefits don't outweigh the cost. You can't just look at any optimization and say "that's not a bottleneck so it's bad to make that optimization", you have to consider the consequences.

Alathon wrote:

Its bad form, its a waste of time, it leads to confusing code structure that later becomes impossible to justify

You're correct that premature optimization is bad because it can lead to "confusing code structure". This happens when you can choose between a clean, simple imeplemenation and an overly complex, theoretically faster implementation.

But that's not the case here. Both methods presented in [link] lead to clean, simple code. The question is: internally, does BYOND handle these methods differently enough that one method performs notably better? Because the inner workings of BYOND are quite mysterious this is a good question to ask.

I'm not sure what your "don't optimize yet" stance would mean here. [link] presents two different ways of doing something. It's not an optimized and unoptimized version, it's just two different methods.

Within the server, the same resources will be used. Across the network, less NPCs might be in view on smaller maps, but perhaps the warping would break the environment data into larger blocks than the rows and columns of continuous movement.

If your maps are procedurally generated, then you might want to wait until you have an identifiable problem. However, cutting or merging hand-crafted maps at a later time isn't as easy. Manual creation can be a long and tedious process that you probably want to do right the first time.

I'd think you'd be happier with smaller maps even if there did turn out to be a slight performance hit. Ignore the game and worry about your own performance when creating and maintaining it. Smaller maps are more versatile and easier to edit. You can add them one at a time and they don't have to form a rectangular grid. If something goes wrong, you can cut a section out without worrying about view and movement issues. You can even change the connections between maps on a whim.