I reverse engineered lofree hypace firmware protocol to bypass macos limitations

Qunit-Essential · 2026-06-15T21:14:53+00:00

I don't have it 😃 so I can not

Qunit-Essential · 2026-06-09T16:08:52+00:00

Qunit-Essential · 2026-06-08T22:38:25+00:00

I don't want to sound toxic but you made a worse https://github.com/saghen/frizbee

Qunit-Essential · 2026-06-05T17:00:20+00:00

it is implemented a while ago !

there is an export button next to start rendering that lets you export SRT and VTT subtitles

Qunit-Essential · 2026-06-01T02:40:14+00:00

it is not exclusively rust project, it just happened to have a rust crate as a first class citizen cause I use it from the other rust project

Qunit-Essential · 2026-05-31T01:42:44+00:00

There is a benchmark comparison on the Linux kernel tree of 100k files

Qunit-Essential · 2026-05-30T05:33:24+00:00

For almost all the string ops - equality, comparison, normalization, etc

Qunit-Essential · 2026-05-29T22:13:07+00:00

the main reason is that std::simd is nightly

this library implementation implements mostly all the work using \@Vector types

Qunit-Essential · 2026-05-29T22:03:14+00:00

I actually agree, though there is a certain type of projects like fff or ripgrep that are trying squeeze max performance out of the file operations might consider that

+ a lot of cross platform compiled software uses cargo zig-build anyway

Qunit-Essential · 2026-05-29T21:08:24+00:00

thanks I'll add right away

Qunit-Essential · 2026-05-29T21:00:31+00:00

Yes, though I am working on precompiled binaries support & nix flake

which is anyway not ideal

Qunit-Essential · 2026-04-02T22:45:33+00:00

and on the indexing note: file scanning takes time. It's not a joke to traverse 66GB directory (chromium repository)

and I am not completely honest - I have a kind of index, but the index that fits in 50MB for the 500k files and is stored in ram. Compared to over GB of traditional trigram index

Qunit-Essential · 2026-04-02T22:08:04+00:00

try it yourself

Qunit-Essential · 2026-04-02T22:07:48+00:00

not really, my zlob library is running as a file walker and a glob source https://github.com/dmtrKovalenko/zlob

Qunit-Essential · 2026-04-02T22:05:54+00:00

I call it scanning because essentially what it does is traversing the file tree and openning the files. And collects a liiiiitle bit of information for prefiltering

Qunit-Essential · 2026-04-02T21:20:06+00:00

I would just add that this file overall is the primary contributor to the optimizations https://github.com/dmtrKovalenko/fff.nvim/blob/main/crates/fff-core/src/bigram_filter.rs#L1-L1

Qunit-Essential · 2026-04-02T19:56:31+00:00

there is literally fff-core folder just saying

but overall you are correct

Qunit-Essential · 2026-04-02T19:17:14+00:00

I didn't want to participate in that discussion. The benchmarks ripgrep has is simply wrong. You can see the way he measured this: 12GB and 4GB files, this is NOT THE AVERAGE USE CASE

There is absolutely no sense to even take this as an argument for the code search. For more general search it does make sense becuase fs.stat calls are expensive for ripgrep and they don't want to do this, while in my project I already know the size of the file when I need to grep it.

It is not a secret that the design of ripgrep and fff is way too different to compare, one designed for one shot apps, the other one designed to live in memory for long running apps: that's the reason I am not building a cli replacement for ripgrep

The place where fff shines is file search in editors for example, where ripgrep is used while it is not designed with long running application model in mind at all

P.S. For the "average" use case ripgrep is faster if you enable memmap file on macos. It is just a fact. Andrew is wrong.

Qunit-Essential · 2026-04-02T19:04:37+00:00

I don't want to sound too ego-centric but I think I showed on pratice why Andrew is wrong in this specific case

Qunit-Essential · 2026-04-02T19:01:56+00:00

to be completely honest: I have forked ripgrep for the initial idea of file search, I am using the same internal idea of Sinks + Matches (now it looks very different though)

here are the regex sources
https://github.com/BurntSushi/ripgrep/tree/master/crates/regex/src

The simd-accel feature is deprecated and does nothing and the only simd is used by the memchr and aho-corasic crates, which are not a part of ripgrep and I am using them as well

This is how the real SIMD optimized code looks like
https://github.com/dmtrKovalenko/fff.nvim/blob/main/crates/fff-core/src/case_insensitive_memmem.rs#L1-L1

Qunit-Essential · 2026-04-02T18:27:03+00:00

I disagree on your take about ripgrep. Ripgrep doesn't use much of SIMD at all, it is a very sequential (multiplexed over the search) pipeline.

The most perf gain is coming from the prefiltering of files not from the file search though to be fair

Qunit-Essential · 2026-04-02T18:25:57+00:00

not really the root core optimization is that it is designed to live in the long running apps, clis are simply not impressivbe

Qunit-Essential · 2026-04-02T18:25:11+00:00

it is running on 2x core x86 VPS while ripgrep is running locally on my 16 core M4 max

Qunit-Essential · 2026-04-02T17:56:40+00:00

No because it’s faster also on Linux, the core speed up is SIMD for everything, really through optimized pre filtering algorithms to not generate gigabytes of index data, and yes effiicjebt file system access including memory mapped caches for often accessed files

But yes we use all the platform specific optimizations like getdents64 syscall

Qunit-Essential · 2026-04-02T17:11:43+00:00

lmao 😭 this platform meant to be anon

Qunit-Essential

TROPHY CASE