본 게시글은 SA-MP forum에서 발췌한 글입니다. 원문을 보시려면 여기를 클릭하세요.
초보 스크립터들에게 아주 중요한 글입니다. 이해를 돕기 위해 나름대로 해석해 보았습니다.
의견이 있으시면 댓글로 남겨주세요.
Why you shouldn't make your strings 256 cells big
글자를 쓸 때 배열을 256개나 사용하면 안되는 이유
Contents
- Contents
- Introduction
- Background
- Why shouldn't you use 256?
- Packed strings
- When should I use 256?
- Conclusion
Introduction
서문
People have some VERY odd views about strings in PAWN, mostly to do with their lengths.
사람들은 PAWN의 문자열에 대해 아주 이상한 생각을 하고 있습니다. 특히 그 길이에 관해 말이죠.
Many people think that strings can not be longer than 256*, why, I don't know, seems like an arbitrarily imposed limit to me with no need for it, and indeed no limit exists.
많은 사람들은 문자열 길이가 256자(한글 128자)보다 길 수 없다고 생각하는데요, 왜죠? 전 모르겠습니다. 전혀 쓸데없이 제멋대로 만든 제한 같은데요, 당연히 문자열 길이에 제한같은건 없습니다.
Many other people think that all strings have to be 256 for no apparent reason, no matter how long they're making the string.
또 다른 많은 사람들은 모든 문자열 크기가 256이어야 한다고 생각합니다. 확실한 이유 없이 말이죠. 문자열을 만드는데 길이는 전혀 문제되지 않습니다.
A string in PAWN is exactly the same as any other array, people seem to have no major problems with other arrays, so why strings?
PAWN 언어의 문자열은 다른 배열과 완전히 같습니다. 사람들은 보통 배열들은 큰 문제없이 잘 사용하는 것 같은데요, 근데 왜 문자열은 이렇죠?
*Note that most people use either 255 or 256, but these are equally as rubbish as each other.
*사람들이 256자가 아닌 255자를 쓰기도 하는데요, 둘 다 그저 갈곳없는 쓰레기일 뿐입니다. (순간 저도 감정이입)
Background
배경지식
A string in PAWN is just an array of characters, no different to any other array.
PAWN언어의 문자열은 그저 글자 하나하나가 모인 배열일 뿐입니다. 다른 배열과 다를 바가 없습니다.
Strings are NULL terminated, this means they all have the character '\0' (NULL) at the end (ASCII code 0, different to the character '0' which has an ASCII code of 48).
문자열은 널 문자로 종료됩니다. 즉 모든 문자열은 '\0' 이라는 널 문자열을 끝에 가지고 있습니다(아스키 코드로 0입니다. 아스키코드 48에 해당하는 글자 '0'(아라비아 숫자 0) 과는 다릅니다).
If you have the following string:
만약 이런 글자가 있다고 칩시다:
PAWN Code:
It is really 3 cells long - one for the 'h', one for the 'i' and one for the NULL character to signal the fact that the string has finished.
이 문자열은 셀 크기가 3입니다(정말로) - 'h'가 들어간 배열 하나, 'i'가 들어간 배열 하나, 그리고 글자가 끝났다는 표시로 쓰는 널 문자 하나 말입니다.
You could also write it as:
Or:
또는:
Where 104 and 105 are the ASCII characters for 'h' and 'i' respectively and 0 is the code for the NULL terminator.
아스키 코드 104와 105는 각각 'h'와 'i'에 해당하며 0은 널 문자에 해당합니다.
In PAWN all variables are set to 0 when they're declared,
PAWN언어에서 모든 배열은 선언될 때 0으로 초기화합니다.
this means when you do:
이 말은 이렇게 할 때:
You're really doing:
사실은 이렇게 하고 있다는 거죠:
for (new i = 0; i < 256; i++)
{
str[i] = 0;
}
It's more optimised than that but it still takes time.
위가 아래보다 간략하긴 하지만 여전히 시간이 걸립니다.
Why shouldn't you use 256?
어째서 256개를 쓰면 안되죠?
- It's slow
- 1. 느려요
As explained in the background all variables are set to 0 when they're initialised, the more variables you have the more time it takes to set them all to 0.
방금 '배경지식'란에서 설명했듯이 모든 변수들은 선언할 때 0으로 초기화됩니다. 따라서 더 많은 배열을 선언할수록 그 배열들을 0으로 초기화하는 데 시간이 많이 걸립니다.
There is optimised inline assembly to do this, not interpreted PAWN,
간략화된 인라인 어셈블리가 이 과정을 처리하기에 PAWN에서는 나타나지 않지만,
but it's such a significant concern that AMXModX wrote another operator, very similar to new,
AMXModX(PAWN과 비슷한 건데 FPS게임에도 쓰입니다)에서는 new와 매우 비슷한 연산자를 사용하는데 여기서는 커다란 문제가 됩니다.
which declared a variable but didn't blank it's memory, just to get round this exact problem.
그 언어에서는 변수를 선언해도 메모리를 비우지 않아서 곧장 문제에 빠지게 됩니다.
(PAWN에서 모든 변수를 선언할 때 0으로 초기화하는 이유를 설명한 겁니다 : 역자주)
- You don't need it (1)
- 2. 그렇게 많이 필요하지 않습니다.-1
Take this post I saw very recently (this prompted me to write this post):
최근에 제가 본 사례 하나를 들겠습니다. (이 글을 보고나서 본 게시물을 작성하게 되었습니다)
{
new rmcmd[256];
format(rmcmd,sizeof(rmcmd),"Only moderators level %d+ can use this command!",reqlvl);
return SendClientMessage(playerid,Green,rmcmd);
}
We'll assume that there is a maximum of 10,000 admin levels to be on the safe side (0 to 9999),
여기서 우리는 안전을 위해 운영자 레벨 (코드에서 moderator level을 말합니다. 변수로는 reqlvl이 있네요)이 10,000개 있다고 가정할 겁니다(0에서 9999까지),
so the longest number that will be inserted into this string is 4 characters long.
따라서 글자에 들어갈 숫자(reqlvl) 길이는 4개까지 될 수 있겠네요.(%d에 9999가 들어가는 경우를 가정)
Only moderators level %d+ can use this command!
By my count there are 47 characters in that string, 2 of which are the "%d" which won't appear in the final string, so 45 to go in the final string.
제가 세 보니 저 문자열에는 47개의 글자가 들어가네요. 그 중 2개는 "%d" 즉 게임에서 출력되는 문장에는 나오지 않는 글자니 총 문장 길이는 45가 되겠네요.
We've already ascertained that the longest the number will be is 4,
방금 우리가 %d대신 들어갈 숫자의 최대길이를 4로 가정했었죠.
(if you want to be on the REALLY safe side, the longest a PAWN integer can possibly ever be is 11 characters (-2147483647))
(혹시 정말로 안전하게 하시려면 PAWN에서 가장 긴 숫자의 길이가 11자(-2147483647)이니 11로 할 수도 있겠죠)
and we know that all strings require a NULL at the end, so the longest this string can ever possibly get to is:
그리고 말씀드렸듯이 모든 문자열은 마지막에 널 문자를 필요로 합니다. 따라서 이 문자열이 가질 수 있는 최대 길이는:
47 - 2 + 4 + 1 = 50
50 cells, so why use 256, it's just a waste of 206 cells (824 bytes - that's nearly a kilobyte of wasted memory)?
그니까 배열 50개면 됩니다. 왜 256개를 쓰는거죠? 셀 206개를 버리는 꼴인데 말이죠.(824 바이트입니다 - 32bit * 206cell - 거의 1킬로바이트를 메모리에서 낭비하는 셈이 되는 거죠)
- Max input is 128
- 3. 입력되는 글자의 최대길이는 128입니다
The SA:MP chat box has a maximum line length of 128,
SA-MP의 채팅창은 최대 128자를 표현할 수 있습니다.
if someone types something you know it will never be longer than 128 ever.
따라서 누군가 글자를 입력했을 경우 절대 128자를 넘어갈 수가 없습니다. (한글은 2바이트니 64자입니다 물론 배열은 128개)
This includes text and commands, so why use a buffer twice that length to process the input?
명령어와 텍스트 모두 포함되는 말입니다. 그니까 입력받는 글자를 처리하는대 배열을 왜 2배나 선언하나고요.
- Max output is 128
- 4. 출력되는 글자의 최대길이는 128입니다
The SA:MP chat box has a maximum line length of 128,
SA-MP의 채팅창은 최대 128자를 표현할 수 있습니다.
if you want to send a message to someone it cannot be longer than 128, so why make a buffer bigger than that?
따라서 누군가에게 메세지를 보낼 경우 절대로 128자를 넘어갈 수 없습니다. 뭐하러 문자열 길이를 더 크게 선언합니까?
(얃홍 숨겨 놓을라구? +_+)
If your message involves some form of user input (e.g. a "/me" command) then using a variable 128 big is recommended as there's no way to determine how long what they will type will be,
단, 당신이 보내는 메세지가 유저가 입력한 글자를 보여주는 경우(예 : "당신은 /me 명령어를 입력했습니다") 같은 경우는 배열을 128보다 크게 선언하는 게 좋습니다. 왜냐면 유저가 얼마나 긴 명령어를 입력할지 모르기 때문이죠.
(아실지 모르지만 배열의 최대 선언량보다 글자가 더 많이 들어가면 서버는 '폭파' 됩니다)
but you know it cannot be longer than that.
하지만 그래도 그 글자가 128자를 넘어갈 수 없다는 걸 알고 계시죠.
- You don't need it (2)
- 5. 그렇게 많이 필요하지 않습니다 -2
{
new string[256], cmd[256];
cmd = strtok(cmdtext, idx);
if (strcmp(cmd, "/num", true) == 0)
{
format(string, sizeof (string), "Random number: %d", random(27));
SendClientMessage(playerid, 0xFF0000AA, string);
}
}
There are a whole load of things wrong with that code,
저 코드에서는 엄청나게 잘못된 점이 많지만,
but unfortunately it's an example of very common coding patterns.
불행히도 이런 코드 형태는 수많은 사람들이 사용하는 형태랍니다.
Ignoring the fact that they're using strtok, that's an entirely separate issue, it's still VERY bad coding:
이 코드가 strtok함수(이것도 사실 전혀쓸데ㅇ벗음)를 사용한다는 사실을 무시해도, 배열 크기는 별개의 문제고, 여전히 나쁜 코드입니다:
string[256],
cmd[256];
Why two?
왜 두개나 선언하세요?
Why do you need one huge string for the command and another huge string for data you will be using after you know which command was entered,
명령어를 위해 엄청나게 긴 문자열 하나를 선언해놓고도, 그리고 이미 어떤 명령어가 입력되었는지 확인했는데도, 글자를 표현하기 위해 또 엄청나게 긴 문자열을 선언해뿌렸네요.
and thus no longer have need for the information in the command variable?
cmd라는 배열은 더이상 쓸모도 없잖아요?
Just reuse it else you're doubling the time from point 1.
우선 앞에서 말했듯 초기화하는 시간부터가 2배가 걸립니다.
(서버가 느려지고 서버가'폭파'되는 상황의 원인이 되는 겁니다)
Why 256?
왜 256자죠 ?? 르응??
As explained above you know for a fact it can never be longer than 128.
방금 위에서 설명했듯 입력받는 글자(cmdtext)의 길이는 128을 넘어가실 수가 없습니다.
If you do reuse the variable for the output although you know the output will not be longer than 18 characters this is not inefficient as you have need for the variable to be longer to store all the input if required.
출력할 때 random에서 나오는 숫자를 포함한다고 해도 총 문장이 18자를 넘어갈 수 없다는 사실을 알고 있는만큼 이는 삽입되는 문장이 더 긴 배열길이를 요구하지 않는 한 비효율적입니다.
A more efficient version would be:
더 효율적으로 작성하면 이렇게 될 겁니다:
{
new string[128]; // cmdtext 의 길이는절대로 128자를 넘어가지 않습니다
string = strtok(cmdtext, idx);
if (strcmp(string, "/num", true) == 0)
{
format(string, sizeof (string), "Random number: %d", random(27)); // 여기서는 오직 18자만 필요하지만 위에서는 128자가 필요했으므로 배열의 크기는 정당화됩니다
SendClientMessage(playerid, 0xFF0000AA, string);
}
}
- Stack usage
- 6. 스택 사용 (아 겁나게 중요해부립니다)
When you call a function it's memory is allocated on a thing called the stack (or heap, but they use the same memory space for simplicity's sake we'll just use stack),
함수를 호출할 때 변수는 스택이라고 불리는 메모리에 할당됩니다. (heap라고도 하지만 같은 메모리 공간을 사용하므로 편의상 스택이라고만 하겠습니다)
function memory cannot be statically allocated because a function may call itself, requiring all the memory to be duplicated.
함수 메모리는 정적으로 할당되어 있을 수 없습니다. 함수가 자신을 호출할 수 있기 때문이죠(재귀). 이때 메모리는 중첩되게 됩니다.
This memory area is called the dynamic memory. Example:
이 메모리 공간을 dynamic 메모리라고 부르죠. 예를 듭시다:
stock StackUse()
{
new str[9];
format(str, sizeof (str), "gVar = %d", gVar);
SendClientMessageToAll(0xFF0000AA, str);
if (gVar)
{
gVar--;
StackUse();
}
}
That function will get called once and allocate 9 cells on the stack for it's use, it will then call itself and allocate another 9 cells, then call itself again and allocate yet another 9 cells.
저 함수는 한번 불려지면 변수 사용을 위해 스택에 변수 9개를 할당합니다. 그리고 자신을 호출하게 되어 또다른 9개의 변수를 할당하게 되고, 또다시 한번 더 호출하게 되어 변수 9개를 할당하게 됩니다. (코드를 잘 읽어 보세요)
After it's been called 3 times there are 27 cells allocated on the stack.
따라서 이 함수는 3번 호출되어 총 27개의 변수가 스택에 할당되게 됩니다.
By the third call "gVar" is 0, so the function doesn't call itself and instead ends, removing it's 9 cells from the stack.
3번째 호출될때 gVar라는 값이 0이 되고, 함수는 더이상 자기자신을 호출하지 않게 되어 종료되고, 스택에서 9개의 변수를 제거하게 됩니다.
This passes control back to the previous instance of the function, which also ends and removes it's 9 cells, as does the first instance of the function,
이렇게 되면 함수는 이전의 호출단계로 돌아가게 되고, 역시 함수가 종료되어 9개의 변수를 제거합니다. 이러면 다시 첫 호출단계로 돌아가게 되어,
so now there are 0 cells on the stack from this function.
이 함수가 종료될 때 스택에는 변수가 남지 않게 됩니다.
(지금까지 stack에 대해 대강 설명하였습니다. stack은 비커같은 구조로 나중에 들어온 데이터가 먼저 나가게 되는 원리를 가지고 있습니다. 고등학교 '정보사회와 컴퓨터' 201페이지 참고)
Now image this code:
이제 이런 코드가 있다고 생각해봅시다:
gVar = 2;
stock StackUse()
{
new str[256];
format(str, sizeof (str), "gVar = %d", gVar);
SendClientMessageToAll(0xFF0000AA, str);
if (gVar)
{
gVar--;
StackUse();
}
}
Exactly the same, but by the time it's been called 3 times from itself it's allocated 768 cells (3072 bytes, 3 kilobytes) on the stack compared to the 27 cells (108 bytes, 0.1 kilobytes, a reduction of over 2800%) of the original.
위의 코드와 완전히 똑같습니다만, 이번에는 자기자신을 3번 호출한 후에 스택에 변수 768개를 불러오게 됩니다(3072바이트, 3KB).
위에 써놓은 코드에서 불러오는 27개의 변수(108바이트, 0.1KB)와 비교하면 2800%나 많은 양이 스택에 쌓이게 됩니다.
(아시겠나요 메모리 낭비가 장난이 아닌 겁니다 저 데이터 량이 30MB라고 한번 생각해보세요 30*28 = 840MB = 다운)
Some of you may have seen this message (or one like it) when compiling:
아마 여러분 중 몇몇은 컴파일할 때 이런 메세지(아님 비슷한)를 본 적이 있을 겁니다:
Code size: 776 bytes
Data size: 528 bytes
Stack/heap size: 16384 bytes; estimated max. usage: unknown, due to recursion
Total requirements: 17904 bytes
Or:
아니면:
Code size: 588 bytes
Data size: 512 bytes
Stack/heap size: 16384 bytes; estimated max. usage=10250 cells (41000 bytes)
Total requirements: 17684 bytes
This means that the compiler has detected that you are using more stack/heap space than is available.
이것은 컴파일러가 당신이 사용 가능한 stack/heap 공간보다 더 많은 양의 공간을 사용하고 있다는 것을 감지했다는 표시입니다.
(이것은 에러입니다 그냥 지나쳐서는 안되는 문제입니다!!)
A lot of import!ant information is stored on the stack, such as who called the current function, so PAWN knows where to return to.
스택에는 많은 양의 중요한 정보가 저장되어 있습니다. 예를들면 누가 이 함수를 호출했는지 같은 거 말입니다. 따라서 PAWN에서는 어디에 return값을 돌려줄지 알 수 있습니다.
If you use too much memory, because of the way information is allocated, you can overwrite the stack information,
만약 정보가 할당되는 방식 때문에 너무 많은 메모리를 사용하게 되면, 스택에 쓰여있는 정보를 겹쳐쓰게 되고,
returning to a random point in code and almost certainly crashing.
결국 코드의 임의적인 부분으로 돌아가게 되어 거의 크래시(서버 '폭파')가 나게 되죠
(이게 스택 오버플로우 입니다 말그대로 비커에 물을 너무 많이 담아서 물이 넘쳐흘러버린거죠)
At the very least you will get corrupted data where it's been overwritten by other data.
만약 그렇지 않다 해도 최소한 특정 데이터가 다른 데이터에 의해 훼손되는 현상이 발생해버립니다.
When people get this message the standard advice is to use "#pragma dynamic", which is a workaround, not a fix -
사람들이 이런 메세지를 접하게 될 때 하는 조언은 보통 '#pragma dynamic' 을 사용하라는 건데요, 이건 스택의 양을 늘리는것 뿐이지 문제를 해결하는 것은 아닙니다.
I find it very odd that something the size of YSI can not generate this error but people's tiny scripts can, don't you?
제 YSI를 사용해서는 이런 에러가 발생하지 않지만 (YSI가 좀 큽니다..ㅋㅋ) 사람들의 작은 스크립트로는 이런 에러가 발생할 수 있습니다. 이상하다고 생각하지 않습니까?
The first error I posted means that you are trying to use more stack space than is available, but because there are functions calling themselves the compiler can't say exactly how much more.
제가 첫번째로 적은 에러는 사용할 수 있는 스택 공간보다 더 많은 공간을 사용하고 있는데, 이는 함수가 자기자신을 호출하고 있기 때문이며 그 양이 얼마나 되는지 컴파일러가 확실히 알 수 없을 때 나타납니다.
Note that the compiler can't determine how many times a function may call itself, even in the example above the number could change somewhere else in the program, and often it's not a constant anyway.
컴파일러는 그 함수가 얼마나 스스로를 호출할지 알 수 없다는 사실을 알려드립니다. 프로그램 어딘가에서 해당 변수값을(위의 예에서는 gVar였죠) 바꿀 수 있기 때문이죠. 그리고 보통 그 값들은 일정하지 않기 때문입니다.
The second error was generated by a program with no recursion.
두번째로 적은 에러는 재귀함수가 없는 프로그램에서 나타나는 경우입니다.
This does apply to ALL arrays, but strings are a major culprit.
이러한 에러는 모든 배열에 해당하지만, 문자열이 주로 용의선상에 오릅니다.
Packed strings
문자열 압축하기
A feature of PAWN rarely used in SA:MP (owed partially to the inability of certain natives to support it) is packed strings.
PAWN언어 의 기능 중 SA-MP에서 거의 쓰이지 않는 문자열 압축이라는 기능이 있습니다.(이걸 지원하기 위해 특정한 native를 무력하게 만들었습니다... 이부분 해석이 확실하지 않습니다.)
Regular strings store one character per cell and a cell is 4 bytes long (making 256 long strings exactly a kilobyte in size),
보통 문자열은 변수 하나에 한 글자씩을 저장하고 변수의 크기는 4바이트입니다(32bit, 따라서 256개의 글자를 만들면 그 크기는 1KB가 됩니다).
packed strings store 4 characters per cell:
압축된 문자열은 변수 하나에 4개의 글자를 저장할 수 있습니다:
Unpacked:
압축되지 않음:
string[12] = "Hello there"; // 12 cells, 48 bytes
변수 12개, 48바이트
Packed:
압축됨:
string[12 char] = !"Hello there"; // 3 cells, 12 bytes
변수 3개, 12바이트
These strings are well documented in pawn-lang.pdf so I won't go into too much detail here,
이런 문자열에 대한 설명은 pawn-lang.pdf에 자세히 나와 있기에 여기에 자세히 쓰지는 않겠습니다만,
pawn-lang.pdf(자세히 안쓴다고 하네요. 이거보고 읽으세요)
but if you have large arrays of strings to store it would be well worth your effort to read up on packed strings and use them for storage, if not manipulation.
만약 글자를 저장할 많은 양의 배열이 필요한데 솜씨가 부족하다면 문자열 압축에 대한 내용을 읽고 활용하시는게 좋겠네요.
If this method were used on the ReturnModeratorCmd example above,
이 방법을 저 위쪽에 써놓은 예시 (이거보고 글을쓰게 됐다는 예시) 에다가 적용하면,
combined with using a decent size string would reduce the memory consumption of that function from 1 kilobyte (1024 bytes) to 50 bytes,
배열 크기를 알맞게 맞추어서 그 함수에 대한 메모리를 1KB에서 50byte로 줄일 수 있게 됩니다.
that's a reduction of over 2000%
이때의 절약 효율은 2000%를 넘습니다.
(제가 pawn-lang.pdf에서 읽어본바로는 pack기능은 영어같은 1바이트글자만 된다는것 같습니다. 제가 한글을 가지고 실험해 보도록 하겠습니다.)
When should I use 256?
배열크기를 256으로 해야 할 때
Having said all this, there are times when large arrays may be useful, but they should be used sparingly only when needed.
이렇게 말씀드리긴 했지만, 가끔씩 커다란 배열이 필요할 때가 있습니다. 하지만 필요할때만 알뜰하게 써야 합니다.
- SQL
SQL queries can be very long, I've written ones where I've needed a string almost 1024 cells in length to contain it,
SQL 쿼리는 아주 길 수 있습니다. 제가 사용해보기로 거의 1024개의 셀이 필요한 적이 있었습니다.
however this is just an extension of the "You don't need it" points, in this case you DO need it.
하지만 이건 예시를 들기 위해 사용한 말일 뿐입니다. 보통은 그렇게 긴 배열이 필요하지 않습니다.
- File reading
- 파일 읽기
This is an example of unbounded input.
이건 입력에 제한이 없는 전형적인 예입니다.
If you read a line from a file you have no way of knowing how long it is and assigning memory to fit it all and unlike player text input it could be any length.
파일에서 줄을 읽을 때는 그 줄이 얼마나 길지 알 수가 없습니다. SA-MP의 메세지창과 달리 어떤 길이가 될지 모르므로, 모든 경우를 맞춰줘야 합니다.
In this case a nice round number like 256 can cover almost all eventualities.
이런경우 배열크기가 256정도면 거의 모든 가능성을 커버할 수 있습니다.
Conclusion
결론
"If in doubt - miss it out". There are very few cases where massive arrays are useful,
"의심간다면 - 줄이세요". 많은 양의 배열이 필요한 경우는 거의 없습니다.
think about what you do to determine the size of any other array based on what you want it for
어떤 배열이든지 간에 원하는 내용을 실현하기 위해서 몇 개나 필요할지 생각해서 스크립팅 하세요.
and apply the same process to strings.
그리고 같은 원칙을 문자열에도 적용하세요.