tiny_sqlite
crystal
tiny_sqlite | crystal | |
---|---|---|
2 | 239 | |
66 | 19,119 | |
- | 0.4% | |
0.0 | 9.8 | |
10 months ago | 8 days ago | |
Nim | Crystal | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
tiny_sqlite
-
A Cost Model for Nim
I did some work on Nim's hash tables back in 2020, specifically with OrderedTable, comparable to a Python dict where insertion order is preserved. I stumbled on this table module in a roundabout way, via Nim's database module, db_sqlite. The db_sqlite module was much slower than Python for simple tests, and on investigation, I found that it didn't automatically handled prepared statement caching like Python's sqlite3 module. There were some other issues with db_sqlite, like blob handling and null handling, which led me to a different SQLite interface, tiny_sqlite. This was a big improvement, handling both nulls and blobs, and the developer was great to work with. But it also didn't support prepared statement caching. I filed an issue and he implemented it, using Nim's OrderedTable to simulate an LRU cache by adding a new prepared statement and deleting the oldest one if the cache was too big:
https://github.com/GULPF/tiny_sqlite/issues/3
Performance was hugely improved. There was another LRUCache implementation I played with, and when using that for the statement cache, performance was 25% faster than OrderedTable. That didn't make much sense to me for a 100-entry hash table, so I started running some tests comparing LRUCache and OrderedTable. What I discovered is that OrderedTable delete operations created an entirely new copy of the table, minus the entry being deleted, on every delete. That seemed pretty crazy, especially since it was already showing up as performance problems in a 100-entry table.
The tiny_sqlite developer switched to LRUCache, and I did some work on the OrderedTable implementation to make deletes O(1) as expected with hash table operations:
https://github.com/nim-lang/Nim/pull/14995
After spending a lot of time on this, I finally gave up. The problems were:
- the JSON implementation used OrderedTables and never did deletes. JSON benchmark performance was rather sacred, so changing OrderedTables to be slightly slower/larger (I used a doubly-linked list) was not desirable, even if it changed delete performance from O(n) to O(1)
- the Nim compiler also used OrderedTables and never did deletes
- Nim tables allowed multiple values for the same key (I did help get that deprecated).
- alternatives were proposed by others that maintained insertion order until a deleted occurred, but then it could become unordered. That made no sense to me.
The TLDR is, if you use Nim tables, don't use OrderedTable unless you can afford to make an copy of the table on every deleted.
Current Nim OrderedTable delete code: https://github.com/nim-lang/Nim/blob/15bffc20ed8da26e68c88bb...
Issue for db_sqlite not handling nulls, blobs, statement cache: https://github.com/nim-lang/Nim/issues/13559
- Mastering Nim – now available on Amazon
crystal
- A Language for Humans and Computers
-
Top Paying Programming Technologies 2024
27. Crystal - $77,104
-
Crystal 1.11.0 Is Released
I like the first code example on https://crystal-lang.org
# A very basic HTTP server
- Is Fortran "A Dead Language"?
- Choosing Go at American Express
- Odin Programming Language
- I Love Ruby
-
Ruby 3.3's YJIT: Faster While Using Less Memory
Obviously as an interpreted language, it's never going to be as fast as something like C, Rust, or Go. Traditionally the ruby maintainers have not designed or optimized for pure speed, but that is changing, and the language is definitely faster these days compared to a decade ago.
If you like the ruby syntax/language but want the speed of a compiled language, it's also worth checking out Crystal[^1]. It's mostly ruby-like in syntax, style, and developer ergonomics.[^2] Although it's an entirely different language. Also a tiny community.
[1]: https://crystal-lang.org/
-
What languages are useful for contribution to the GNOME project.
Crystal is a nice language that's not only simple to read and write but performs very well too. And the documentation is amazing as well.
-
Jets: The Ruby Serverless Framework
Ruby is a super fun scripting language. I much prefer it to python when I need something with a little more "ooomph" than bash. It's just...nice...to write in. Ruby performance has come a long way in the last decade as well. There's libraries for pretty much everything.
My modern programming toolkit is basically golang + ruby + bash and I am never left wanting.
I do find Crystal (https://crystal-lang.org/) really interesting and am hoping it has its own "ruby on rails" moment that helps the language reach a tipping point in popularity. All the beauty of ruby with all of the speed of Go (and then some, it often compares favorably to languages like rust in benchmarks).
What are some alternatives?
Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
pg - Very simple PostgreSQL async api for nim.
nwaku - Waku node and protocol.
go - The Go programming language
adix - An Adaptive Index Library for Nim
Elixir - Elixir is a dynamic, functional language for building scalable and maintainable applications
ratel
mint-lang - :leaves: A refreshing programming language for the front-end web
homebrew-core - 🍻 Default formulae for the missing package manager for macOS (or Linux)
Odin - Odin Programming Language