Symbol 프로그래밍?

https://en.wikipedia.org/wiki/Symbol_(programming)

심볼. 굳이 우리말을 쓰자면 기호. 기호 개발. (뭔가 어색하다?)

오늘 페북에서 ECMAScript 6 표준에 Symbol이 정의되어 누군가가 MDN에 번역해 주었다.
Symbol – Javascript | MDN
심볼. 아마 자바, 닷넷, 자스 개발자 등에게 어찌보면 생소한 개념일 수 있다.
하지만 루비 개발자나 Object-C 개발자는 이미 있기 때문에 알고 있을 것이다.
이 심볼 개발방법은 여러 스크립트 언어 등에서 채택한 개발론이다.

간단하게 설명하자면, “가장 유일한 식별자”다.
뭐?
루비(Ruby)의 심볼이란?

정의는 한 번. 더 이상 변경할 수 없는 값이다.
여기까진 상수와 비슷한 개념이다.
그렇다면 값 비교 시 “A” 와 “A”가 같다? 심볼은 그딴거 없다.
그렇다. 심볼의 값은 일종의 사람만이 식별하기 위해 존재하는 값일 뿐.
문자열 값은 리터럴을 정의할 때마다 메모리가 늘어난다. 설령 변수를 지정하던 상수를 쓰던.
간단하게 생각해보자.
“A” “BC” “DEF”… 이들은 언제 바뀌지 못하기 때문에 불명확한 메모리를 할당받으며 서 있다.
당연히 그런 만큼 메모리를 잡아먹는다.
하지만 심볼은 딱 정해진 메모리만큼만 먹는다. 바뀔 일도 없기 때문에. 확장할 일도 없고.
그러니 메모리 애끼는 효과가 있다.

그렇다면 어따가 쓰냐고?
가장 쓰임새가 많이 쓰이는 곳이 바로 “해시 값”을 다루는 데에 쓰인다.

JS에 새로 정의된 Symbol을 통해 예제 하나 뿌리겠다.
ES6 Symbol Test 예제

var obj = {};
var a = Symbol("a")

obj[a] = "a";
obj[Symbol.for("b")] = "b";
obj["c"] = "c";
obj.d = "d";

for (var i in obj) {
   console.log(i); // logs "c" and "d"
}

console.log(obj[a]); //logs "a"

심볼 “a” 란 해시 키에 “a” 값을 넣었다.
근데… 반복문에는 나타나지 않는다.
그렇다. 주소 값이니 나오지 않을 수밖에.
대신에 명시적으로 해시 키를 정의하면 가져올 수 있다.
이런 이득이 있다는 것이다.
그렇다면 이런 특징으로 얻을 수 있는 이득이 뭐가 있을까?

간단하다. hidden 키와 값을 넣을 수 있는 그런 개발이라면 모두 가능하다.
일종의 private identifier 인 셈이다.

자. 이제. 자바와 닷넷도 이런 개념이 존재하냐고 물어보는 사람이 있을 것이다.
당연히 없다. 근데 자바와 닷넷은 문자열에 한해 인터닝(Intern) 이라는 개념이 있다.

자바의 String.intern() String.intern()은 메모리를 아낄 수 있다?

  • String pool에 있는 각종 문자열에 equals해서 같은게 있다면 그 놈을 반환하고,
  • 같은게 없다면 String pool에 String object를 추가하고, 추가한 놈을 반환한다.

즉, String 객체를 리터럴로 관리하여 메모리 절약을 꽤하는 개념이다.
그렇다 보니 아래와 같은 단점이 존재한다.

  • 우선 String 객체를 하나 만들어야 한다.
  • String의 equals 메소드를 이용해서 String pool에 있는 놈을 찾아서 비교해야 한다. ( 시간이 걸림 )
  • String pool에 들어 갔으므로, 더 이상 GC(가비지컬렉션)의 대상이 될 수 없다. ( 메모리 관리 불가 )

그렇기 때문에 적재적소에 잘 관리해야 한다는 점이 있다. 그래도 같은 문자열을 객체로 정의하여 메모리 쳐묵보단 낫다.

참고로 닷넷도 아주 동일한 개념이다. String.Intern() 메소드 쓰는 건 매한가지이며 동일하기 때문에 별도의 설명은 생략하겠다.

자. 자바와 닷넷이 문자열을 관리하는 방법이 여기서 나온다. 리터럴은 자바나 닷넷이나 내부 풀을 따로 운영하여 저장한다. GC에 걸리는 걱정 없이.
(물론 new String 처럼 객체로 만들었다면 걸릴 각오는 해야 하지만.)

뭔가 삼천포로 빠진 것 같다.
하지만 메모리를 아껴서 빠르고 유연한 개발을 꾀하는 개발자는 있다.
이럴 때 필요한 것이 뭐고, 뭘 알아야 하는지는 개발자의 사명인 것이다.
그러기 위해 이 포스트를 올렸다.
그럼 이제…

끗.

composite / 2015년 11월 17일 / Piss Development / 0 Comments

심심하면 보는 2012 전 세계 웹 서버 순위

2012년 기준이지만, 다들 관심 없나보다. 워낙 자바만 고집하는게 한국사회라. 좀 병신같지만.

그래도 웹 서버 점유율은 잠시 웃어주고 넘어가자.

  1. 단연 Apache. 오픈소스지만 오랜 노하우와 초보부터 프로까지 접할 수 있는 접근성이 큰 요인으로 작용한다.

    딱히 무슨 말이 필요한가. PHP와 Apache는 여전히 최상의 조합인데.

  1. 비즈니스 앱에서 독보적인 마소의 IIS. 비즈니스에서는 윈도우 서버 구매비용에 비해 낮은 구축 비용과 세팅 비용이 매력으로

   작용해서 아직도 많이 쓰고 있는 편이다. 여전히 IIS 6을 돌리고 있는 웹사이트가 많으며

   (.NET 3.5 이하 또는 기존 ASP가 많이 호스팅되다 보니.)

   IIS 7 이상은 마소 파트너가 아닌 이상.. 스타트업 업체도 이걸로 구축하는 업체가 많지 않다. 초기 비용이 비싸니까..ㅋㅋ

   그래서 마소가 WebsiteSpark, BizSpark 같은 프로그램 운영해도 아는사람 많지 않은게 함정.

  1. 추월하고 있는 Nginx. 웹 서버 성능이 최강이라 알려져 있다. 특히 리버스 프록시에 강해서 WAS 따로 둬도 강력할 정도.

    WAS는 Web Application Server는 다들 알겠지만 자바에 한정짓지 마라. 자바 뿐만 아니다. 괴발자들아.

    자바를 비롯해 닷넷도 WAS가 가능하고(물론 ASP.NET 종속적이 아니면), 뜨고 있는 node.js 와 Ruby, Python 같은

    여러 서버 스크립트도 WAS 로 돌려 Nginx 에서 호스팅이 가능하고, 새로 뜨고 있는 스타트업 웹사이트에서도 그렇게 쓰고

    있다. 요즘 스타트업 사이트들이 그런 식으로 돌리다 보니 추월한 것이지.

    nginx와 PHP 조합? 단연 우수하다. 아파치 조합보다 더 빠른 성능을 자랑한다.

  1. 갑자기 다시 뜨고 있는 lighttpd. 이녀석은 애초부터 HTTP 서버에 군더더기를 제거해 HTTP 서버”만” 돌리겠다는 이념(?)으로

    만들고 있는 오픈소스 서버다. 그렇다 보니 서버 분산과 클라우드, CDN의 유행이 퍼지면서 정적 컨텐츠를 빠르게 전달하는

    용도로 주목을 받고 있는 듯 하다. 여태까지 잠잠해지다가 뜬 거 보면. 내 개인적인 생각이지만.

    예를 들면 css나 js, 이미지 같은 서버단 처리가 없는 정적 컨텐츠 말이다.

  1. 구글은 구글에 구걸하면 구할수 있습니까?

전 세계 웹 서버 점유율에서 한국의 경우는 “당연히” 아파치가 우세하다. 일본도 마찬가지고. 근데 중국은 IIS.. 읭?

어쨌든 지금 웹 서버와 개발 트랜드가 조금씩 변화하고, 뜨고 있는 언어가 늘어나면서 경쟁은 치열해 지고 있는 것이 현실이다.

그래봐야 님은 자바에 아파치 톰캣이면 어느 누구도 두렵지 않다고 하겠지만. 아니면 닷넷의 경우 IIS가.

근데.. 님들아. PHP가 웹 사이트 언어 순위 아직도 1위랍니다. 앞으로도 1위고. 의미없는 언어우월주의 허세떨지 마시길 괴발자님.

참고자료

May 2012 Web Server Survey – http://news.netcraft.com/archives/2012/05/02/may-2012-web-server-survey.html

Most popular web servers by country – http://w3techs.com/blog/entry/most_popular_web_servers_by_country

Poll Results: Server side language of choice? – http://css-tricks.com/poll-results-server-side-language/

composite / 2013년 6월 13일 / 미분류 / 0 Comments