Folly Code Review · 29/89

folly Conv 성능 비교 — sprintf·stringstream 대비

2026년 6월 5일 · Hawk · 3분 읽기

#한 줄 요약

folly::to는 sprintf보다 약 5배, stringstream보다 약 15배 빠르다. 비결은 2-digit lookup table, SWAR 8-digit parse, if constexpr dispatch로 런타임 분기 제거다.

#동기

server에서 integer ↔ string은 매 요청 수십 번 발생한다. RPC ID, log line, query string, JSON 숫자, metric counter. 하나당 100 ns만 차이 나도 throughput 5-10% 차이로 환산된다.

1억 req/s 클러스터에서 변환 한 번이 200 ns냐 30 ns냐만 달라져도, 약 170 ns × 100M = 17초의 CPU 시간 차이가 난다. 이 규모에서 stringstream은 사실상 사용 금지다.

#benchmark — int → string

1
benchmark: convert uint32_t to string (1e6 iter, single thread)
2

3
  folly::to<std::string>            22 ns/op
4
  fmt::format("{}")                 32 ns/op
5
  absl::StrCat                      26 ns/op
6
  std::to_string                    65 ns/op
7
  snprintf("%u")                   110 ns/op
8
  std::ostringstream               450 ns/op
9

10
  folly::toAppend (no alloc)         9 ns/op  (in-place)

folly::to는 std::to_string 대비 3배, snprintf 대비 5배, ostringstream 대비 20배. toAppend(buffer 재사용)는 더 빠르다.

#benchmark — string → int

1
benchmark: parse uint64_t from string (length 1-19, 1e6 iter)
2

3
  folly::to<uint64_t>               12 ns/op
4
  std::from_chars                   14 ns/op
5
  absl::SimpleAtoi                  13 ns/op
6
  std::stoull                       42 ns/op (throw on fail)
7
  strtoull                          25 ns/op
8
  std::istringstream(>>)           390 ns/op

std::from_chars(C++17)와 거의 동등. stoull은 throw가 hot path 분기를 비싸게 만들고, istringstream은 locale·rdbuf 비용으로 30배 느리다.

#내부 구현 — 왜 빠른가

#1. 2-digit lookup table itoa

1
// 약식
2
constexpr char gDigitTable[200] =
3
  "00010203040506070809"
4
  "10111213141516171819"
5
  "20212223242526272829"
6
  "30313233343536373839"
7
  "40414243444546474849"
8
  "50515253545556575859"
9
  "60616263646566676869"
10
  "70717273747576777879"
11
  "80818283848586878889"
12
  "90919293949596979899";
13

14
uint32_t u64_to_ascii(char* buf, uint64_t v) {
15
  char* p = buf + max_digits;
16
  while (v >= 100) {
17
    auto idx = (v % 100) * 2;
18
    p -= 2;
19
    p[0] = gDigitTable[idx];
20
    p[1] = gDigitTable[idx + 1];
21
    v /= 100;
22
  }
23
  // 1-2 자리 마무리
24
  if (v >= 10) {
25
    auto idx = v * 2;
26
    p -= 2; p[0] = gDigitTable[idx]; p[1] = gDigitTable[idx + 1];
27
  } else {
28
    p -= 1; *p = '0' + v;
29
  }
30
  // ...
31
}

10진수 division을 2자리씩 하면 한 division으로 두 character. std::to_string은 character 하나씩 처리한다.

#2. SWAR 8-digit atoi

1
// 약식 — 8 자리 정수 한 번에
2
uint64_t parse8(const char* s) {
3
  uint64_t w;
4
  std::memcpy(&w, s, 8);
5
  w -= 0x3030303030303030ULL;            // '0' 빼기
6

7
  // multiply chain — 2자리, 4자리, 8자리 결합
8
  w = (w * 10 + (w >> 8)) & 0x00FF00FF00FF00FF;
9
  w = (w * 100 + (w >> 16)) & 0x0000FFFF0000FFFF;
10
  w = (w * 10000 + (w >> 32)) & 0x00000000FFFFFFFF;
11
  return w;
12
}

이 코드는 32-bit 곱셈 3번으로 8 자리 정수를 만든다. character 단위 ASCII 검사·*10+digit 루프 대신.

#3. if constexpr dispatch

1
// 약식
2
template <class Tgt>
3
Tgt to(StringPiece sp) {
4
  if constexpr (std::is_integral_v<Tgt>) {
5
    return detail::digitsToInteger<Tgt>(sp);   // SWAR
6
  } else if constexpr (std::is_floating_point_v<Tgt>) {
7
    return detail::strToFp<Tgt>(sp);
8
  } else if constexpr (is_string_v<Tgt>) {
9
    return Tgt{sp.data(), sp.size()};
10
  } else {
11
    Tgt out;
12
    parseTo(sp, out);
13
    return out;
14
  }
15
}

분기가 모두 컴파일 타임. virtual call, function pointer 없음. 인라인 가능성이 높아진다.

#다른 라이브러리는 왜 느린가

#sprintf

locale lookup (LC_NUMERIC)
format string parsing (런타임)
variadic argument 처리 (va_list)
모든 conversion specifier 지원 (% 처리)

대부분 unused지만 비용은 항상 지불한다.

#stringstream

ios 상태 관리 (precision, fill, width, locale)
streambuf 가상 호출
sentry 생성/소멸
error flag 갱신

OOP overhead가 누적된다. 한 conversion에 virtual dispatch가 5-6번 일어난다.

#std::to_string

snprintf wrapper (libstdc++/libc++)
그래서 sprintf와 같은 비용

#메모리 효율

folly::to<std::string>(...)는 모든 인자의 size를 미리 계산해 reserve 한다. realloc 0회.

1
// 약식
2
std::string out;
3
size_t total = estimateSpaceNeeded(a)
4
             + estimateSpaceNeeded(b)
5
             + estimateSpaceNeeded(c);
6
out.reserve(total);
7
toAppend(a, &out);  // no realloc
8
toAppend(b, &out);
9
toAppend(c, &out);

absl::StrCat도 같은 전략. std::ostringstream은 매 <<마다 internal buffer를 grow.

#코드 리뷰 포인트

1
// Bad — hot path에서 매번 std::string 생성
2
for (auto& metric : metrics) {
3
  log << folly::to<std::string>(metric.id, ":", metric.value, "\n");
4
}
5

6
// Good — buffer 재사용
7
std::string line;
8
for (auto& metric : metrics) {
9
  line.clear();
10
  folly::toAppend(metric.id, ":", metric.value, "\n", &line);
11
  log << line;
12
}

루프 안에서 buffer 재사용으로 할당 0회. 큰 log writer가 이 패턴.

1
// Bad — float 출력에 std::to_string
2
std::string s = std::to_string(3.14159);   // "3.141590"
3
// "%f" default — locale에 따라 ','로 출력될 수 있다
4

5
// Good — folly 또는 fmt
6
auto s2 = folly::to<std::string>(3.14159);     // locale 비의존
7
auto s3 = fmt::format("{}", 3.14159);

float은 정확도와 locale 둘 다 문제. folly::to / fmt::format는 Ryu/Grisu를 사용해 최단·정확 표현.

#안티패턴

stringstream을 log 한 줄 만드는데 사용: 매 줄 450 ns. fbcode에서는 사실상 금지 사항.
to<std::string>을 반복 호출 후 +=: 임시 string과 reallocation 누적. toAppend를 한 buffer에 누적.
to<int>로 외부 입력 parse, exception을 정상 흐름으로 처리: throw 비율이 높으면 100배 느려진다. tryTo로.

#정리

folly::to는 lookup table + SWAR + if constexpr 조합으로 sprintf 대비 5배, stringstream 대비 15-20배.
std::from_chars와 거의 동등한 속도지만 high-level API.
toAppend로 buffer 재사용 시 할당 0회.
float은 Ryu/Grisu 기반, locale 비의존.
hot path는 buffer-reuse + tryTo 패턴이 정답.