Limits and efficiency in Design Philosophy

ID:265882
 
Dec 4 2008, 7:55 pm
I've heard about the limits BYOND has on what can be in the world, but I don't think I've ever seen a complete list. I've heard the limits are around 65k?

Anyways, I'm just looking for either a link to where these limits might be listed or some more information about these limits. Are they cumulative? (Like, do lists have their limit, or do they simply take away from the main limit) How are literals handled? (Like numbers, etc.)

One main reason that I'm asking is that for a fan game, I put some data from the original game... which takes the form of 32 lists of 100 numbers each. Right now, I just define each list as a global var. Are these 3200 numbers going to be a problem when it comes to efficiency and limits? My other option was to create the list in the code and have it built every time I need to get data from one of the lists, but I wasn't sure whether building a 100 number list regularly would be more strain than just building them once and holding them.
(The numbers are all numbers 1-20, so its not like I'm using very many, just the same ones repeated)
#1 Dec 4 2008, 8:18 pm
Chessmaster_19 wrote:
I've heard about the limits BYOND has on what can be in the world, but I don't think I've ever seen a complete list. I've heard the limits are around 65k?

Anyways, I'm just looking for either a link to where these limits might be listed or some more information about these limits. Are they cumulative? (Like, do lists have their limit, or do they simply take away from the main limit) How are literals handled? (Like numbers, etc.)

One main reason that I'm asking is that for a fan game, I put some data from the original game... which takes the form of 32 lists of 100 numbers each. Right now, I just define each list as a global var. Are these 3200 numbers going to be a problem when it comes to efficiency and limits? My other option was to create the list in the code and have it built every time I need to get data from one of the lists, but I wasn't sure whether building a 100 number list regularly would be more strain than just building them once and holding them.
(The numbers are all numbers 1-20, so its not like I'm using very many, just the same ones repeated)

For the most part, you can safely bet on the number 65535 for internal limits -- 65535 mobs, 65535 list elements, 65535 strings, so on and so forth. It takes a lot of effort to reach this limit, so most projects don't even need to worry about these.

As for your question about numbers and the such, BYOND's internal referencing stashes each unique copy of a string, number or other item exactly once. If you have:

var/a = 20
var/b = 20


...you've used precisely one memory address, and contributed one item toward the limit. This is because 20 is stored for the variable a, and the variable b references the memory location of a. Ultimately, this saves a ton of redundant memory allocations, which is why it takes significant effort to hover around internal limits (and also why operations like if(a == b) work).
#2 Dec 4 2008, 8:43 pm
In response to Mobius Evalon (#1)
Mobius Evalon wrote:
For the most part, you can safely bet on the number 65535 for internal limits -- 65535 mobs, 65535 list elements, 65535 strings, so on and so forth.

Yeah. And for datums and turfs, a bigger limit: ~16.7 million.

As for your question about numbers and the such, BYOND's internal referencing stashes each unique copy of a string, number or other item exactly once. [code]
...you've used precisely one memory address, and contributed one item toward the limit.

Actually, only strings are internally cached, I think. Numbers don't really have a limit of how many you can have; they're a raw-ish data type compared to all the others. A limit of them to mention though is their precision, because all DM numbers are floating-point, but for most common purposes not being able to keep track of huge imaginary numbers isn't a problem.

So, to reiterate, strings and objects work in the way you have described: 
var/mob/mymob = new()
var/M = mymob

var/X = "MyString"
var/Y = X

That only ever produces a single mob and a single string, yeah. The value all four variables contain is a reference to the actual data stored elsewhere.
#3 Dec 4 2008, 8:53 pm
In response to Kaioken (#2)
Turfs are also 'cached'. If the only difference between two turfs is their x, y, and z values, they only count as one turf.

That's why you can have absolutely massive maps. Although you really shouldn't, it's possible.

AFAIK, numbers don't have a 'limit'. Because they're not references to another object in memory - they're raw. I think. We'd need Word of God to be sure.

There probably is a local-var limit of something (Quite possibly 65535), and I'm pretty sure there is an object-variables limit of 65535.
#4 Dec 4 2008, 9:08 pm
In response to Jp (#3)
Jp wrote:
Turfs are also 'cached'. If the only difference between two turfs is their x, y, and z values, they only count as one turf.

Yeah. This isn't quite like the other caching, so I didn't mention it as such. Every turf is still treated as a separate, intractable instance by DM, even though they're "cached" in a way to buff up the limitation.
#5 Dec 13 2008, 9:51 pm
Small tidbit of info, 65536 is the highest number that you can have in 16 bits.

George Gough
#6 Dec 13 2008, 10:11 pm
In response to KodeNerd (#5)
KodeNerd wrote:
Small tidbit of info, 65536 is the highest number that you can have in 16 bits.

Actually 65535 would be the highest; 32767 if it's a signed number.

Lummox JR
#7 Dec 14 2008, 4:31 am
In response to Lummox JR (#6)
Signing bits must require an awfully small pen. >.>
#8 Dec 14 2008, 1:19 pm
In response to Xooxer (#7)
Hehehe, you make joke!
#9 Dec 14 2008, 1:34 pm
In response to Lummox JR (#6)
Darn you Lummox and your correctness.

George Gough
#10 Dec 14 2008, 8:33 pm
In response to Haywire (#8)
Haywire wrote:
Hehehe, you make joke!

I'll actually be lol'ing at that for days to come. It was rather entertaining.