Our great sponsors
-
This has been talked about for years but I believe it's still complicated by C API compatibility. The most recent discussion I see is here:
https://github.com/faster-cpython/ideas/discussions/138
Victor Stinner's experiment showed some performance regressions, too:
https://github.com/vstinner/cpython/pull/6#issuecomment-6561...
-
This has been talked about for years but I believe it's still complicated by C API compatibility. The most recent discussion I see is here:
https://github.com/faster-cpython/ideas/discussions/138
Victor Stinner's experiment showed some performance regressions, too:
https://github.com/vstinner/cpython/pull/6#issuecomment-6561...
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Absolutely everything in CPython is a PyObject, and that can’t be changed without breaking the C API. A PyObject contains (among other things) a type pointer, a reference count, and a data field; none of these things can be changed without (again) breaking the C API.
There have definitely been attempts to modernize; the HPy project (https://hpyproject.org/), for instance, moves towards a handle-oriented API that keeps implementation details private and thus enables certain optimizations.
-
I actually worked on a project that did this. We used a database called "Tile38" [1] which used an R-Tree to make geospatial queries speedy. It was pretty good.
Our dataset was ~150 GiB, I think? All in RAM. Took a while to start the server, as it all came off disk. Could have been faster. (It borrowed Redis's query language, and its storage was just "store the commands the recreate the DB, literally", IIRC. Dead simple, but a lot of slack/wasted space there.)
Overall not a bad database. Latency serving out of RAM was, as one should/would expect, very speedy!
[1]: https://tile38.com/
