daniele_dll
Joined 4 years ago
Karma
102
Submissions
37
Member since
May 31
Recent submissions
Comment · 3 days ago
Comment · 2 months ago
Thank you! I worked super hard to keep the token usage as low as possible.
It's also possible to drive mobile browsers via the MCP, although I really tested only chrome, I have done a bunch of optimization for token usage also on that front but never pushed the testing too much further, if you want to experiment and provide feedback I will be more than happy to check things out!
Comment · 7 months ago
Well if you check the screenshot you will notice that LinkedIn was using about 10x more memory for a few tabs ;)
The most insane one is at +15GB lol
I felt "reductive" reading that LinkedIn was using <3GB for 2 tabs given my experience.
Comment · 7 months ago
I posted because I saw that a few days ago but 2.4GB felt "reductive" considering what I experienced on my machine ;)
Comment · 1 year ago
It's always nice to see someone discovering that mmap is not built for performance but for easyness of data-on-disk management with reasonable speed.
Comment · 3 years ago
Meet Cachegrand, an open-source (BSD licensed) Redis-compatible key-value store designed for speed. Our latest release offers significant improvements, allowing you to use Cachegrand in environments without clustering, while still maximizing performance.
Get started quickly using our Docker image and enjoy the benefits of one of the fastest Redis-compatible caching platforms out there. Cachegrand optimizes performance for both physical and virtual hardware.
Here our github repository https://github.com/danielealbano/cachegrand
We're committed to transparency, so we've made all the raw benchmark data available at https://github.com/cachegrand/cachegrand-benchmarks. We'd appreciate your feedback! Give Cachegrand a try and experience the difference today.
Comment · 3 years ago
This is a valid reason, but makes sense for code bases where the generation takes tens of minutes or more not seconds.
Comment · 3 years ago
Importing a C file into a Python session is a practice that can ---easily--- cause ---a lot--- of headaches, the packages required to build the code as python library and make it importable will vary between systems and make it hard to debug in case of crashes.
I personally would distribuite the pre-compiled binaries, CI + docker makes that much easier.
The fact that "can be done" doesn't necessarely mean that "it's the right way" to do it.
Going back to embedding auto-generated code, focusing on this specific case, are you telling me that a line in the requirements.txt, on a machine where the user is expected to have access to a compiler, is the reason to keep auto generated code in the repository? Sorry, personally it seems a flaky reason.
Also, the very fact that you mention that users don't have superuser privileges should be even more of a reason to use virtual environments, where you don't need super privileges, or if you can't or want to use virtual environments you can still have multiple paths in the PYTHONPATH env variable and you can install packages in a specific paths leveraging the --target of pip or the PYTHONUSERBASE env variable, solving the issue as well.
I would prefer to suggest my users to improve their runtime environment than enable them to improve the chaos.
Comment · 3 years ago
Fully agree with the principle but maybe let's not call Redis "well-written" :)
Redis is a great piece of software because of how much it impacted the "evolution" of Internet not because of the code quality, Redis's code resemble spaghetti code, a lot.
I will push myself and say that nowadays people would get fired for writing code like that!
And before someone start to throw stones (just for the sake of it), here a few examples: - Redis source code is FULL of GIANT files with thousands and thousands of lines of code, decoupling and separation of concerns are basic things! A few examples -- https://github.com/redis/redis/blob/unstable/src/module.c -- https://github.com/redis/redis/blob/unstable/src/cluster.c -- https://github.com/redis/redis/blob/unstable/src/redis-cli.c -- https://github.com/redis/redis/blob/unstable/src/networking....
- talking about auto generated, the repo contains commited auto generated code, a valid reason though really slips my mind (yes, of course I can think of a few, but ... really? :)))
- https://github.com/redis/redis/blob/9c7c6924a019b902996fc4b6... ... that struct feels like an "Italian minestrone", basically a kind of soup where you throw in, literally, all the vegetables you have around and it's great for a soup, a bit less for software engineering though :)
- the naming structure is a bit random at times, there is a mix of camel case, camel case mixed with underscores from time to time, pascal case
This kind of staff might be alright for a 0.3 or 0.4, maybe even for a 1.0, definitely not for a 7.x that has had 15 years to evolve :/ Even in cachegrand, that hasn't got to a v0.2 yet, I tried to avoid these kinda of dramas, in C is quick and easy to get there if you are not careful.
There are plenty of other small things but most of the big dramas should be there.
Comment · 4 years ago
Curious to discover how the hastable implemented in cachegrand ( https://github.com/danielealbano/cachegrand ) - my opensource Redis compatible Key-Value store - can deliver up to 112 million GET op/s and up to 85 million UPSERT op/s?
I have just pushed the new documentation! https://github.com/danielealbano/cachegrand/blob/main/docs/a...
When tested with memtier_benchmark, using the Redis protocol, cachegrand itself, on the benchmarking hardware, thanks to the implemented hashtable can reach up to 5 million GET op/s and up to 4.5 million UPSERT op/s without batching, with it up to 60 million GET op/s and up to 26 million UPSERT op/s!
Also going faster than Redis doing only GET and SET is fairly easy, the very very very early versions of cachegrand (pre 0.1) were doing well over 100M/s of GET and SET on a 32 core / 64 threads machine with pipelining.
Once you start to chuck the rest to make it actually "usable" it's where you start to massively lose performances.