Dennis Forbes가 보고한 Zig `strspn` 병목, SQLite JSON 1.2MB 토큰화서 약 1만2000배 둔화
체스 분석 서비스 운영자 Dennis Forbes는 Linux용 SQLite의 JSON 저장 병목을 Zig의 `strspn` 구현이 남은 문자열을 반복해서 훑는 동작으로 지목했습니다. Forbes는 별도의 1.2MB 파일 토큰화 사례에서 약 1만2000배 둔화를 보고했습니다.
개발 · 최신기사
언어와 프레임워크, SDK와 개발 방식·도구의 변화를 다룹니다.
PostgreSQL 19 병렬 autovacuum, 베타4 시험서 리더 CPU 줄고 전체 시간은 거의 그대로
Alex Georgiev의 PostgreSQL 19 beta4 시험에서 병렬 autovacuum은 리더 CPU 시간을 약 30% 줄였지만, 40만 행·6개 인덱스·죽은 튜플 80만 개를 처리한 전체 시간은 평균 1.31초에서 1.25초로 약 4% 줄어 실행 간 편차 안에 머물렀습니다. 체크섬 온라인 전환은 beta4에서 철회돼 RC1에 포함되지 않았습니다. Craig Kerstiens의 별도 시험에서 REPACK (CONCURRENTLY)는 테이블 접근을 유지하는 대신 `VACUUM FULL`보다 오래 걸렸고 추가 디스크 공간이 필요했습니다.
Lemire, 64비트 환경의 signed 32비트 상수 나눗셈 보정 축소·fastmod 분기 제거
Daniel Lemire가 부호 있는 32비트 정수 나눗셈에서 상수 제수 처리의 보정 단계를 줄이는 방법을 제시하고, 실행 중 제수를 받는 fastmod의 분기 없는 구현을 0.2.0에 반영했습니다. 성능 이득은 제수와 CPU·컴파일러에 따라 달랐습니다.
MariaDB, InnoDB LRU 승격 경로 수정해 일부 시험서 11.8 처리량 2.8배 높여
MariaDB가 InnoDB의 페이지 승격 과정에서 발생하던 전역 뮤텍스 경합을 줄이는 패치를 11.8 브랜치에 병합했습니다. 40스레드·100GiB 버퍼 풀의 읽기 중심 시험에서 11.8 처리량은 수정 전 20,326 QPS에서 수정안 57,052 QPS로 증가했습니다. 특정 벤치마크 결과이며 혼합 읽기·쓰기 작업은 후속 측정 과제로 남았습니다.
Deno 작업 캐시, 비싼 빌드는 10ms로 줄였지만 입력 추적 비용도 따져야
Deno 2.9의 작업 캐시는 `deno.json`에 입력 파일을 지정하면 변경이 없을 때 명령 실행을 건너뜁니다. 한 개발자의 시험에서는 40개 파일을 처리하는 작업이 약 4초에서 9~10ms로 줄었지만, 3,000개 파일을 추적한 캐시 적중은 간단한 명령을 그냥 실행하는 것보다 느렸습니다.
DuckDB.NET 1.5.6.1, 데이터 읽기 최대 12배 빨라져
DuckDB.NET 1.5.6.1은 DuckDB 엔진을 그대로 둔 채 .NET 데이터 리더의 형식 변환과 호출 경로를 개선했습니다. 벤치마크에서 읽기 작업이 최대 12배 빨라졌고, 정수 열을 double로 읽을 때 할당량은 366MB에서 18KB로 줄었습니다.
EQUALP에서 숫자를 해싱하는 천상의 즐거움
Common Lisp의 EQUALP 해시 테이블은 표현이 달라도 수학적으로 같은 숫자에 같은 해시를 부여해야 합니다. ECL 개발자는 이 조건을 지키면서 충돌과 메모리 할당을 줄이는 정규화 방식을 구현했고, 특정 혼합 숫자 벤치마크에서 기존 방식보다 최대 600배 빨라졌다고 보고합니다.
Python 3.14의 concurrent.interpreters, GIL 작업 시간을 3.6초에서 0.9초로 줄이다
Python 3.14의 concurrent.interpreters로 CPU 작업을 네 개의 서브인터프리터에 나누자 네 스레드보다 훨씬 빠르게 처리됐습니다. 다만 인터프리터 하나에는 동시 호출을 하나만 허용하고 시작 비용도 프로세스보다 높아, 데이터 전달 방식과 작업 수명에 맞춘 설계가 필요합니다.
Go 1.28 HTTP/2 파킹: 유휴 연결 5,000개에서 RSS 85~93MiB 감소
Go 1.28 개발 버전은 HTTP/2 연결에서 처리할 일이 없을 때 연결 담당 goroutine을 종료하고, 새 작업이 오면 다시 실행하는 파킹 기능을 추가했습니다. 한 머신에서 유휴 연결 5,000개를 측정한 결과, 파킹을 켜면 같은 바이너리에서 RSS가 84.7~92.6MiB 줄고 goroutine은 5,000개 감소했습니다.
Valkey 9.2의 RDB LZ4 압축, 100만 건 파일을 178MB에서 35MB로 줄여
Valkey 9.2.0-rc1에서 전체 RDB 스트림을 LZ4로 압축하자 반복 구조가 있는 데이터의 파일 크기가 약 80% 줄었습니다. 다만 데이터 종류에 따라 효과가 달랐고, 복제 압축 설정과 릴리스 노트 해석은 작성자가 댓글에서 정정·재검증하기로 했습니다.
Next.js를 제거하자 블로그의 Lighthouse 점수가 모든 항목에서 100점이 됐습니다
정적 블로그에서 Next.js 런타임이 불필요한 JavaScript와 긴 작업을 만든다고 보고 Hono로 옮긴 과정입니다. 글쓴이는 Lighthouse 점수 100점, 빌드 시간 약 40% 단축을 확인했지만 댓글에서는 Next.js의 정적 내보내기와 다른 정적 사이트 생성기도 대안으로 거론됩니다.
소프트웨어가 느린 이유는 느린 언어가 아니라 나쁜 설계다
언어를 C나 Rust로 바꿔도 대부분의 프로그램은 I/O 대기나 이미 최적화된 라이브러리 때문에 크게 빨라지지 않는다고 주장합니다. 프로파일링으로 병목을 찾고 쿼리 수를 줄이거나 작업을 비동기화하는 등 설계를 바꾸는 편이 효과적이라는 조언입니다.
“Rust보다 빠르다”는 주장 반박: Tov의 악의적 벤치마크
Tov의 벤치마크가 Rust보다 빠르다고 주장하지만, 세 사례에서 비교 코드와 선택한 자료구조가 서로 달랐다고 비판합니다. 개선한 Rust 코드에서는 Tov와 비슷하거나 더 나은 성능이 나왔지만, 댓글은 동적 디스패치와 해시 함수의 선택에 따라 비교의 의미가 달라진다고 지적합니다.
Redis 8.4의 digest 기반 SET, 1MB 비교 후 쓰기 지연을 4.4ms에서 1.8ms로 줄여
Redis 8.4의 SET 조건부 옵션 IFEQ와 IFDEQ는 기존 값이나 digest가 일치할 때만 쓰기를 수행합니다. 작성자의 localhost 측정에서 1MB 값에 IFDEQ를 쓰면 기존 GET-후-SET보다 지연이 줄었고, 동시 갱신 실험에서는 재시도 루프로 lost update를 막았습니다. 다만 값의 동일성만 비교하므로 WATCH와 의미가 다를 수 있습니다.
브라우저에는 이미 우선순위 시스템이 있습니다. debounce(300)에는 없습니다
디바운스는 검색을 잠시 미룰 뿐, 실행을 시작한 뒤 메인 스레드를 오래 점유하는 문제는 해결하지 않습니다. 글은 브라우저의 작업 우선순위와 yield를 활용해 긴 작업을 나누고, 취소와 성능 측정을 함께 적용하는 방법을 설명합니다.
Rust 컴파일러에 기대되는 2026년, 그리고 필자에게도
Rust 컴파일러에서는 차세대 trait solver와 Polonius, 병렬 프런트엔드, LLVM 성능 개선 등 오래 진행한 작업이 함께 진척되고 있습니다. 필자는 이를 새 기능 하나의 성과보다 장기적인 내부 정비와 성능 투자가 결실을 맺는 시기로 설명합니다.
PostgreSQL 19 베타의 병렬 autovacuum, 작업자를 늘려도 vacuum 시간은 그대로
PostgreSQL 19 beta4는 autovacuum의 인덱스 정리에 병렬 작업자를 투입하는 설정을 추가합니다. 한 실험에서 autovacuum 작업자의 CPU 시간은 약 30% 줄었지만 전체 vacuum 시간은 약 4%만 짧아졌습니다. 이 결과는 heap 스캔이 병목인 작업에서는 병렬 인덱스 정리만으로 처리 시간이 줄지 않음을 보여줍니다.
HTTP/1 연결 재사용 개선
Go 1.27의 net/http.Transport는 닫을 때 읽지 않은 HTTP/1 응답 본문을 최대 256KB, 50ms 동안 비동기로 읽어 연결 재사용을 돕습니다. 본문을 읽지 않고 상태 코드만 확인하는 예제는 Go 1.26보다 약 5배 빨라졌습니다.
def를 async def로 바꿨더니 블로킹 호출 하나가 FastAPI 앱 전체를 멈췄습니다
FastAPI에서 같은 동기식 HTTP 호출도 일반 def 엔드포인트에서는 스레드 풀로 넘어가지만 async def 안에서는 이벤트 루프를 막습니다. 글쓴이는 부하 실험으로 스레드 풀의 기본 한도 40과 CPU 작업에서 asyncio.to_thread가 제한적으로만 효과를 내는 이유를 측정하고, 프로세스 풀과 스택 추적 워치독을 비교합니다.
Python에서 초당 수십 GB의 JSON을 파싱하기
Python 3.14의 GIL 없는 빌드와 simdjson 바인딩 fastsimdjson을 사용해 7.6GB의 GitHub 이벤트 JSON을 처리한 벤치마크입니다. 64개 스레드에서 초당 66GB를 기록했으며, 필요한 필드만 Python 객체로 만드는 지연 뷰가 성능에 큰 영향을 줍니다.