Maybe I am missing what they meant here, but isn’t the entire point of tree-sitter that you can reuse old trees to make edit updates faster? It is seems quite probable that all the performance gains came from optimising for fixed files with no error recovery, at the cost of how ts is actually used.
So your benchmarks are primarily just “how fast is go’s c interop” rather than any algorithmic improvement on tree-sitter?
Edit: yep, you are just calling a c function in a loop. So your no-op benchmark is just the time it takes for cgo to function. I would not be able to get any perf benefits from e.g. rust
Do you have an equivalent of TreeCursors or tree-sitter-generate?
There are at least some use cases where neither queries nor walks are suitable. And I have run into cases where being able to regenerate and compile grammars on the fly is immeasurably helpful.
At least for my use cases, this would be unusable.
Also, what the hell is this:
> partial [..] missing external scanner
Why do you have a parsing mode that guarantees incorrect outputs on some grammars (html comes to mind) and then use it as your “90x faster” benchmark figure?
Currently it is in the "tech demo" phase. The only people I would recommend using this are people willing to contribute in some form. I would not recommend it as a daily driver hence the "alpha" tag on all the builds.
To be honest, the only part that I would recommend is our tooling that we use for soft-forking Firefox/Gecko, which is where we have the most outside testers and where I am focusing most of my upstream (mozilla-centeral) patches to improving.
I think you are miss interpreting me. I don't want to focus on privacy above all else. To do that well would compromise on the usability of the browser. For example, if I were to advertise it as "privacy focused", I would not feel comfortable unless I included strict anti-fingerprinting, which would break websites.
It is a balancing act, and I won't be collecting or selling your data, but I won't be competing with Librewolf or Tor for the "privacy" market either. However, at the bare minimum, we will be more "private" than Firefox by extent of including uBo and disabling Mozilla's non-critical telemetry by default.
Our website is a touch (read very) out of date. To clarify, we are working on newer features, like the sidebar tabs. Currently, it is a combination of a tech demo and a set of personal preferences (features, extensions, preferences) that I and the other developer would prefer. If you have ideas for new features, I am interested to hear them.
Hi, I am a dev on Pulse Browser. I want to clarify our current development direction (I haven't significant updated the website recently). We have been moving further away from privacy and towards developing/iterating on features faster than Firefox is willing to, along with providing sane defaults.
For example, we have been experimenting with a opera/vivaldi-like method of accessing Firefox's sidebar. Whilst you could technically achieve this via patching `omni.ja`, you would need to repatch it every update. At that point, it might as well be a custom browser.
Sorry about Vercel's insight stuff, not sure how that got enabled, but it should be disabled now (or whenever Cloudflare invalidates your cache).
Maybe I am missing what they meant here, but isn’t the entire point of tree-sitter that you can reuse old trees to make edit updates faster? It is seems quite probable that all the performance gains came from optimising for fixed files with no error recovery, at the cost of how ts is actually used.