ExportXMLWordPrintableJSON

    • Type: Epic
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: BSON, Performance
    • None
    • BSON Perf Improvements
    • Python Drivers
    • Not Needed
    • To Do
    • 0
    • 0
    • 0
    • 100
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Context

      While investigating PYTHON-6109 (abi3 support), several standalone performance wins in the existing BSON C extension were identified.
      They are independent of that effort and benefit the current driver: using benchmarks I measured ~15% on the standard bson tests from removing temporary bytes allocations for string keys/values, 52% encode / 19% decode for datetime using O(1) calendar math, ~20% faster tz-aware datetime encode, and faster encode dispatch and a decode fast-path fix.

      Summary

      While investigating PYTHON-6109 (abi3 support), we identified several standalone performance wins in the existing BSON C extension. They are independent of that effort and benefit the current driver. This epic tracks landing them, protected by a proper benchmarking regression gate:

      • Interleaved A/B BSON benchmarking against a base ref, plus an Evergreen PR regression gate (PYTHON-6096)
      • Remove per-element temporary bytes allocations for string keys/values via PyUnicode_AsUTF8AndSize (PYTHON-6097) — ~15% on the standard bson tests
      • Replace the time64 library's loop-based calendar math with Hinnant's O(1) algorithm (PYTHON-6098) — 52% datetime encode / 19% decode
      • Avoid allocating a second datetime when encoding tz-aware datetimes (PYTHON-6099) — ~20% faster tz-aware datetime encode
      • Exact-type fast path for encoder dispatch (PYTHON-6107)
      • Fix is_dict_class detection so document decodes use the fast PyDict_SetItem path (PYTHON-6108)

      Motivation

      Who is the affected end user?

      All PyMongo users. BSON encode/decode is on the hot path of every operation.

      How does this affect the end user?

      Not blocked — this is pure performance uplift. Users doing string-heavy or datetime-heavy workloads see the largest gains.

      How likely is it that this problem or use case will occur?

      Main path — every document encode/decode pays these costs today.

      If the problem does occur, what are the consequences and how severe are they?

      Users are currently getting lower performance for bson encode and decode than what is possible with these improvements.

      Is this issue urgent?

      No required timeline; targets the next minor release.

      Is this ticket required by a downstream team?

      No, driver-internal.

      Is this ticket only for tests?

      No — PYTHON-6097/6098/6099/6107/6108 are functional C-extension changes. PYTHON-6096 is benchmarking/Evergreen infrastructure only.

      Cast of Characters

      Engineering Lead:
      Document Author:
      POCers:
      Product Owner:
      Program Manager:
      Stakeholders:

      Channels & Docs

      Slack Channel

      [Scope Document|some.url]

      [Technical Design Document|some.url]

            Assignee:
            Unassigned
            Reporter:
            Steve Silvester
            None
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              None
              None
              None
              None
              None
              None