Dennis Forbes가 보고한 Zig `strspn` 병목, SQLite JSON 1.2MB 토큰화서 약 1만2000배 둔화
체스 분석 서비스 운영자 Dennis Forbes는 Linux용 SQLite의 JSON 저장 병목을 Zig의 `strspn` 구현이 남은 문자열을 반복해서 훑는 동작으로 지목했습니다. Forbes는 별도의 1.2MB 파일 토큰화 사례에서 약 1만2000배 둔화를 보고했습니다.
최신기사
AI, 개발 도구, 오픈소스, 보안과 인프라의 변화와 이용 조건을 설명하는 최신 기사와 해설입니다.
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개 파일을 추적한 캐시 적중은 간단한 명령을 그냥 실행하는 것보다 느렸습니다.
리눅스 7.4 FAT32 패치, 파일 공간 사전 할당 최대 265배 빨라져
리눅스 7.4에 FAT32 파일 공간 사전 할당을 여러 클러스터 단위로 처리하는 패치가 들어갔습니다. 개발자 벤치마크에서는 5.3~265.4배 빨라졌지만, 최대치는 동기 마운트에서 실행한 특정 `fallocate()` 시험 결과입니다.
DuckDB.NET 1.5.6.1, 데이터 읽기 최대 12배 빨라져
DuckDB.NET 1.5.6.1은 DuckDB 엔진을 그대로 둔 채 .NET 데이터 리더의 형식 변환과 호출 경로를 개선했습니다. 벤치마크에서 읽기 작업이 최대 12배 빨라졌고, 정수 열을 double로 읽을 때 할당량은 366MB에서 18KB로 줄었습니다.
EXT4, 대용량 쓰기 성능 높이는 선택형 buffered iomap 추가
Linux 7.4의 EXT4에 선택형 buffered iomap 지원이 추가됩니다. 대용량 쓰기에서 성능 향상을 보였지만 일부 기능과 마운트 모드가 호환되지 않으며, 조건에 따라 기존 I/O 경로로 자동 전환합니다.
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의 정적 내보내기와 다른 정적 사이트 생성기도 대안으로 거론됩니다.
Git 2.56의 last-modified 명령은 한 디렉터리에서는 빠르고 흩어진 파일에서는 느립니다
Git 2.56의 실험적 git last-modified는 같은 디렉터리의 파일 40개를 조회할 때 파일별 git log보다 3.5배 빨랐지만, 저장소 곳곳의 파일에서는 더 느렸습니다. 디렉터리와 그 하위 경로를 함께 넘길 때 인자 순서에 따라 결과가 누락되는 문제도 확인했습니다.
소프트웨어가 느린 이유는 느린 언어가 아니라 나쁜 설계다
언어를 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 스캔이 병목인 작업에서는 병렬 인덱스 정리만으로 처리 시간이 줄지 않음을 보여줍니다.