포인터에 대한 고찰

포인터의 강력함을 부정하는 것은 아니지만, 과연 포인터의 성능은 어떨까?

다음과 같은 상황이 고민이 되는 경우가 있겠습니다.

struct buf {
int data[1024];
}

struct sendStruct{
struct buf sendData;
}

struct sendStruct temp;

위 같은 경우 temp의 크기는 4096 bytes 가 되겠지요.(뭐 더 될수도 있겠고...)

temp를 다른 Task에게 메세지 큐로 보낸다고 하면, 4096을 보내야 되니 매우 오버해드가 큽니다..

해결책으로, 다음과 같이 하면 되겠지요.

struct buf {
int data[1024];
}

struct sendStruct{
struct buf *sendData;
}

struct sendStruct temp;
temp.sendData = malloc( sizeof( struct buf ) );

위와 같이 한다면, 다른 Task에게 메세지 큐로 temp 변수를 보낸다고 해도 겨우 4byte만 보내도 됩니다.

효율적이지요

그렇기 때문에, 현재 나는 구조체의 멤버들을 아주 많이 포인터로 선언해 놓고 쓰고 있습니다.

다음과 같은 코드를 생각해 볼 수 있습니다.

appList->pOBEApp->pParam->u.integer = NULL;

위 코드는 NULL이란 것을 넣기 위해 소위 '땡겨오기'를 4번이나 하고 있습니다.

'땡겨오기' 라고 표현하는게 맞는지 모르겠지만,

이걸 하게되면 컴파일 시점에는 u.integer의 주소를 알 수 없으므로

실행시마다 메모리로 부터 땡겨오게 될 것입니다. (아직 확인 안해봤지만, 그럴것이라 생각됨)

즉, u.integer 의 주소를 알기 위해 cpu는 메모리 access를 4번이나 더 해야합니다.

그리고 그렇게 해서 얻어낸 u.integer의 주소에 NULL이란 값을 적는 일을 수행합니다.

appList.pOBEapp.pParam.u.integer = NULL

위의 코드에 비해 4배 이상 느리게 될 것입니다. for문을 돌리게 되면 문제는 더 심각해 집니다.

디어셈블을 하면 알겠지만...

이 내용이 사실이라면, 포인터를 너무 남용하는것은 성능상으로도 좋지 않은것 같습니다.