Nodejs

TL;DR 100만개의 item에 대해서 Map을 활용해 자료구조의 resizing 비용이 큰지 비교하는 간단한 실험입니다. 실험이 적절하지 않아 resize 비용이 속도에 영향을 주는 정도인지는 알 수 없었습니다. Map을 초기에 intialize해서 resize를 1번 일으키는 것보다 그냥 매번 resize를 일으키되 찾는 연산을 작은 데이터 셋에서 하는게 더 좋다는 것만 알게 되었습니다. Resizing을 줄이는게 의미 있을까? 뭔말이여 100만개의 데이터를 돌리는데 Resizing 비용이 아까웠다. [지난 실험][1]에서 백만개 item으로 구성된 json array에 대한 uniqueBy를 수행하면서, resizing 비용이 클거라는 생각에 직접 구현을 고민 했었습니다. 하지만 정말로 큰게 맞을까요? chatGPT에게 물어보니 초기에 값을 넣어주는 방식을 채택하면 resize에 들어가는 비용이 줄어든다고 하더군요. 합리적인 말이라고 생각해서 실험해보기로 했습니다. ...

TL;DR native set, lodash, ImmutableJS의 Set을 이용한 uniqueBy 구현체의 속도/메모리 사용량/CPU 사용량을 봅니다. CPU 사용량이 많아지는 것에 대한 걱정이 없다면 ImmutableJS의 Set을 활용한 uniqueBy를 구현해 사용하세요. 꽤 많은 데이터에 대해서 uniqueBy를 빠르게 돌리고 싶다. 왜 와이 백만개 정도 되는 데이터를 돌릴 필요가 발생했다. 백만개 item 정도 되는 json array에 대한 uniqueBy를 할 필요가 생겼습니다. 실제로 백만개 item에 대해서 테스트는 하기 어려워서 그냥 native set을 이용해 개발했습니다. 개발을 하고 보니, 더 빠른 구조가 있을지 궁금해 졌습니다. chatGPT에 물어보니, TypedArray를 사용해 직접 구현하는 방법과 ImmutableJS를 이용해 구현하는 방법을 제안해 주었습니다. ...

TL;DR node에서 배치잡을 돌리고 싶다. child_process, cluster, worker_thread 비교 io intensive + cpu intensive일 때의 비교 child_process 쓸거 함수별 사용 시점 정리 node에서 배치잡을 돌리고 싶다. 왜와이 쉽고 빠르게 배치작업을 하고 싶다. 일회성 배치작업을 해야 하는 상황이 생겼습니다. 쉽고 빠르게 익숙한 NodeJS로 배치작업을 하고 싶었습니다. io와 cpu 모두 사용하는 작업으로, 딱봐도 오래걸리는 작업이었습니다. 그냥 해보았습니다. 싱글 스레드로 작업을 진행했습니다. Promise.all로 일부 데이터만 작업을 진행했더니 20분이 걸렸습니다. 도저히 전체를 한번에 돌릴 수는 없다고 생각이 들었고, 빠르게 처리하는 방법을 찾게 되었습니다. ...