웹 이미지 용도별 JPEG XL과 AVIF 비교
여러 이미지와 품질 설정을 대상으로 AVIF와 JPEG XL 인코더의 파일 크기, 인코딩·디코딩 시간, 메모리를 비교했습니다. 일반적인 손실 사진과 스크린샷에서는 대체로 AVIF가 유리하지만, 무손실 압축과 일부 이미지에서는 JPEG XL이 앞서며, 작성자는 기본값으로 AVIF 4:4:4를 권합니다.
최신기사
AI, 개발 도구, 오픈소스, 보안과 인프라의 변화와 이용 조건을 설명하는 최신 기사와 해설입니다.
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 객체로 만드는 지연 뷰가 성능에 큰 영향을 줍니다.
조금 더 빠르고 작아진 curl
curl의 새 성능 테스트를 바탕으로 여러 내부 함수와 구조체를 개선했습니다. Base64 디코딩은 40%, URL 인코딩은 약 4배 빨라졌고, 전송에 쓰이는 구조체와 메모리 사용량도 줄었습니다. 일반적인 전송에서 사용자가 체감할 차이는 크지 않을 수 있다고 설명합니다.
console.log 한 줄이 연간 4만 달러를 쓰고 있었습니다
요청 본문을 매번 JSON으로 직렬화해 로그 문자열을 만든 뒤, 운영 환경의 로그 수준이 warn이라 버리는 코드가 API 지연과 서버 비용을 키웠습니다. 로거가 출력 여부를 판단하기 전에 문자열을 만들지 않도록 고친 뒤 p99 지연이 낮아지고 인스턴스를 줄여 연간 약 4만 달러를 절감했다고 설명합니다.
Apple iPhone 18 Pro 리뷰 — 작은 본체에 담은 성능, 해결되지 않은 약점
Notebookcheck는 A20 Pro의 높은 성능과 컴팩트한 크기를 장점으로 꼽지만, 전작보다 발열 제어와 배터리 사용 시간이 나빠졌다고 평가합니다. 낮은 PWM 주사율과 카메라 센서 크기도 약점으로 지적했으며, Reddit에서는 특히 배터리 테스트 결과와 측정 방법을 두고 논쟁이 벌어졌습니다.
Python 3.15와 3.14 성능 비교 — 큰 폭의 인코딩 개선이 전체 평균을 끌어올렸습니다
Windows 11에서 Python 3.14.8과 3.15.0을 pyperformance로 비교한 결과, 두 시스템 모두 전체 기하평균 기준 약 1.45배 빨라졌습니다. 다만 Base32·Ascii85·Base85 인코딩의 큰 개선을 제외하면 약 1.20배이며, Base16과 일부 정규식 작업은 느려졌습니다.
NumPy 2.5에서 np.searchsorted를 최대 25배 빠르게 만들기
NumPy 2.5의 np.searchsorted는 여러 검색 키를 묶어 처리하는 이진 탐색 알고리즘으로 NumPy 2.4보다 벤치마크에서 최대 25배 빨라졌습니다. 검색 상태를 쿼리마다 저장하던 방식을 바꾸고, 독립된 검색의 메모리 접근을 겹쳐 수행해 대기 시간을 줄였습니다.
미안하지만, 여전히 생각해야 합니다
AI 에이전트가 Ruby on Rails 앱을 Rust와 Elixir로 다시 쓴 사례를 비교하며, 코드를 읽지 않고 신뢰성 있는 시스템을 만들기 어렵다고 주장합니다. 부하 테스트 결과는 처리량뿐 아니라 오류율, 이벤트 전달 지연, 메모리 사용량까지 함께 봐야 하며, 각 언어와 설계의 트레이드오프를 따져야 합니다.
DuckDB 2.0은 왜 더 빠른가
DuckDB 2.0 alpha의 성능 개선을 S3 비동기 I/O, 재귀 CTE, JSON용 VARIANT 저장 방식으로 나눠 직접 측정합니다. 테스트 환경에서는 S3 읽기가 2~3배, 깊은 Git 커밋 계보 탐색이 최대 160배 빨라졌으며, JSON 필드 쿼리와 저장 공간도 개선됐습니다.
Valkey 9.2의 forkless BGSAVE, 메모리 급증을 350MB에서 10MB로 줄였습니다
Valkey 9.2.0-rc1의 forkless BGSAVE는 쓰기 부하가 있는 1.1GB 데이터셋에서 저장 중 메모리 증가량을 평균 354MB에서 9.9MB로 줄였습니다. 대신 저장 시간은 3초에서 5~6초로 늘고 쓰기 처리량은 약 15% 감소해, 메모리와 성능 사이의 실제 비용을 보여줍니다.
Redis와 Dragonfly 직접 비교 — 아키텍처와 운영상 차이
Redis와 Redis 프로토콜 호환성을 갖춘 Dragonfly를 같은 환경에서 살펴보고, 두 제품의 아키텍처와 운영상 차이를 정리합니다. Dragonfly는 멀티코어와 메모리 효율을 앞세우지만, 지속성·클러스터·호환성과 운영 이력은 실제 워크로드로 확인해야 합니다.
B-트리의 귀환 — 빠르고 페이지화 가능한 노드 레이아웃 설계
TUM 연구진이 가변 길이 키를 지원하는 B-트리의 노드 레이아웃 여섯 가지 최적화를 구현하고 비교합니다. 키 특성과 작업 비율에 맞춰 레이아웃을 고르는 적응형 B-트리는 메모리 전용 인덱스와의 성능 차이를 줄이며, 조밀한 정수 키에서는 완전 조밀 리프가 조회·삽입 성능을 크게 높입니다.
p99, 로드 밸런서, 오토스케일링: 직접 실험하며 익히는 지연 시간
평균 지연 시간만 보면 놓치기 쉬운 꼬리 지연을 세 가지 브라우저 시뮬레이터로 살펴봅니다. 지연 분포, 로드 밸런서의 장애 대응, 오토스케일링의 반응 시간을 직접 조작하며 운영 지표를 해석하는 감각을 익힙니다.
읽기 위주 작업에서 RwLock이 치르는 성능 비용
한 서비스에서 RwLock과 Crossbeam의 epoch 기반 원자 포인터를 비교한 벤치마크입니다. 16,384개 항목을 순회할 때 항목마다 락을 잡고 푸는 대신, 순회당 epoch를 한 번 고정하자 읽기 처리량이 약 15.9k에서 229.1k로 늘고 지연 시간도 줄었습니다.
9MB WebAssembly 모듈, 바이트를 줄이지 않고 더 빠르게 느끼게 만든 방법
Recraft Studio는 9.2MB CanvasKit WebAssembly 모듈을 더 일찍 요청하고 React Suspense 대기열에 묶인 작업을 앞당겨 캔버스 첫 렌더 시간을 15~19% 줄였습니다. 파일 크기는 그대로였지만, 실험군 약 1만8천 명을 대상으로 측정한 결과 p90에서 약 1.9초 빨라졌습니다.
벤치마크는 밀리초 단위로
마이크로벤치마크 입력 크기를 조절해 실행 시간을 약 300ms로 맞추자는 제안입니다. 고정 비용의 영향을 줄이면서도 반복 측정과 사람의 체감 비교를 빠르게 할 수 있지만, 정확한 통계나 특정 환경의 성능 검증이 필요한 작업에는 별도 접근이 필요합니다.
Schwartzian Transform 다시 발견하기 — Flutter 성능 글에 댓글을 남긴 이유
문자열 날짜를 정렬 비교 때마다 파싱하면 Flutter UI가 멈출 수 있습니다. 글쓴이는 Schwartzian Transform으로 정렬 키를 한 번만 계산하는 방법을 설명하고, Dart 3 Records를 활용한 구현과 1만 건 벤치마크 결과를 소개합니다.
Janet을 x32로 빌드하기 — 메모리는 줄이고 64비트 명령어는 유지합니다
Linux x32 ABI는 64비트 명령어 세트를 유지하면서 포인터를 32비트로 줄입니다. Janet 실험에서 메모리 사용량은 벤치마크별로 8~32% 감소했고 실행 시간은 대체로 비슷했습니다. 다만 x32 지원을 제공하는 배포판이 드물고, 구형 32비트 모드인 -m32는 성능이 크게 떨어졌습니다.