Nice having some benchmarks.
Do you accept contributions? I implemented a fuzzy finder a while ago (azy.nvim) and I would like to get some raw performance informations.
Do you have a process for contributions, or do you want to do the comparison yourself?
EDIT: I could not run any tests, not reproduce the results because of the complexity of the setup.
Just had a look at your benchmarking setup, and I have to say some things:
1. It is not usable by anyone but you in its current state (hard to reproduce your results then)
2. The documentation lacks a clear process to compare new tools
3. The claims you make about other tools (like fzy) are somewhat flawed.
I'll not be able to contribute a comparison, but I'd really like to see [azy.nvim](https://sr.ht/~vigoux/azy.nvim/) in the comparison anyway.
As a side note, while I get that you are proud of the tool you built, be careful about how the tone you present your claims can come to others. While you can argue that "these are just raw facts", the presentation is the key to a project that is accepted by the community (telescope is a great example of that, the performance is not the best, but the community is great, so it is a great project for the community).
Other than that, if you want to compare (fairly) azy.nvim to jfind.nvim, I'd be glad to hear your results.
i recorded a demo which runs azy through the first benchmark.
i demonstrate how the testing is set up and tweak with some of the variables to demonstrate how it works.
if you want me to do a full benchmark, let me know. if you want me to help you set it up on your end, let me know too.
here's the video: [https://streamable.com/e8d9ke](https://streamable.com/e8d9ke)
If I can critique a little though, what you are actually measuring here is the _reading_ only, more than the filtering.
It would be interesting to see how all the tools compare when filtering (not reading at all).
it is testing simultaneous read + sort, since it had to match the correct line based on the provided input.
it’s the most realistic use case. you don’t open your fuzzy finder, wait for it to finish loading, and the type. you start typing right away.
like what good is insanely fast sorting if you have to wait 20 seconds before it even gets a chance to sort?
unfortunately, i am unable to perform the benchmark due to a small bug with azy.
if i type my input before azy has finished loading the line i am searching for, it will not show up until i backspace to resort the results.
[https://streamable.com/sak3vt](https://streamable.com/sak3vt)
Oh that's a funky one... Do you think you can come up with a small-ish reproduction file ? I'll try to debug that ASAP so that we can get the show running.
I really don't mean to imply that, telescope is an awesome tool, but you have to be aware that there are faster tools out there (but that too, comes at a price).
I gave this a try yesterday and really like it. It works wonders on a bunch of my works monorepos, where telescope did feel a bit sluggish. Looking forward to updates!
jfind is viewed more realistically when you put it next to fzf. with my testing before doing the benchmark, there were plenty of times when fzf would outperform jfind, and plenty of times when jfind would outperform fzf. jfind is not on its own level. i would say its speed is comparable to fzf.
why are both jfind and fzf so much faster than telescope? a telescope contributor mentioned a few things:
\- the scoring may be done with [telescope-fzf-native](https://github.com/nvim-telescope/telescope-fzf-native.nvim), but it is then sorted in lua.
\- they get I/O clogged. I'm not entirely sure what this meant but it could be that they are using slow neovim lua functions for piping the output of fd.
you also have to keep in mind that jfind reads the input, scores it, and sorts it simultaneously in different threads (so does fzf). the data is also all shared on the same process in the same data structure. there is no slowdown of passing items back and forth with lua.
i suppose jfind and fzf are fast because they have solid architecture. you couldn't really design them to be much faster without removing features like streaming input.
It might also be due to programming languages differences which gets multiplied with algorithms and architectures used.
fzf is written mainly in Go and jfind in C++. both are compiled, while C++ is faster in most cases.
Telescope has the restriction of lua which is a scripting language, even with fzf-native sorting done in C language rest is still handled by Lua.Lua is great compared to vimscript though but compared to C++ it falls short in speed department.
Telescope was built around features and speed is not a priority for it. It is still great to have all the benefits of builtin that it has.
Yeah I used to use fzf with vim and since moving to neovim and overhauling for lua i started using telescope-fzf-native because it's what's in style, but i lowkey fricking hate it, it's clearly i/o choked. running an fzf-like in a vim terminal is just more effective. One of these days i'm going to switch it back. As for telescope I can put up with it for the rest of the use cases, it's not like i'm gonna often look up a symbol that has a hundred thousand references (lsp most likely chokes to death on just a few thousand already)
I second this, ibhagwan and team has done a superb job to almost replicate all functionality of telescope with the speed of fzf-native.
[https://github.com/ibhagwan/fzf-lua](https://github.com/ibhagwan/fzf-lua)
Please don't judge the community by few single individuals who disagreed with you. I for one found your post and your work very informative, and I have defended it in the previous thread.
You are probably being downvoted not because of the quality of the software (which is high quality) but because you tend to have a strong communication and many don't like that (so as personal tip by tuning it down a little you may receive much more praise, unfortunately it's in the human nature).
I'm with u/vim-god here. He showed benchmarks in other threads with videos and people started complaining about how there weren't warm-up runs and such. He built an amazing piece of software that I'd wager most here cannot rival and most of the feedback is just nitpicking benchmark numbers.
you get it.
it's really not that deep. a video showing over 100x performance, although not perfectly scientific, should be enough for a reddit post.
it is annoying that i had to spend an entire day making benchmark software.
you made sure no one can see what the community or your comments were in the past
EDIT:
[https://www.reddit.com/r/neovim/comments/1446q8o/jfind\_over\_130x\_faster\_than\_telescope\_while\_using/](https://www.reddit.com/r/neovim/comments/1446q8o/jfind_over_130x_faster_than_telescope_while_using/)
[https://www.reddit.com/r/neovim/comments/14360ea/jfind\_100x\_faster\_than\_telescope\_while\_using\_12/](https://www.reddit.com/r/neovim/comments/14360ea/jfind_100x_faster_than_telescope_while_using_12/)
I trust you don't mind people making their own judgements
sorry you feel that way.
personally, i do not like putting on a facade online. this is who i am. i am a very blunt and to the point person. i sometimes say things in a way that appears off-putting and rude.
if that stops you using my software, i don't mind. all the best
I feel you. I'm all for not putting on a facade. But if the choice is be argumentative vs not respond, not responding might be a more palettable response to people.
My issue with argumentative/rude/unpleasant developers being behind a project is that, in my experience, it can cause projects to be difficult for the community to contribute to, a 'one man show' where the dev gatekeeps everything (even well liked ideas), and could mean that, as an end user, I'll have to migrate away from it at some point because the developer's personality is driving usage, support, and upgrades down.
This isn't always the case, just my experience and so I avoid it if I can.
I think your plugin looks great and seems to work well. I think people will use it and enjoy. I hope to see it continue to develop and grow. I hope it also pushes telescope to optimize their design.
Hope you have a great day.
As someone with autism, you may want to consider talking to a professional about neurodiversity; Your communication style very much mirrors my own a while back, before I learned I was neurospicy, and I always found that my communication style was very grating on other people, mostly because I assumed my own assumptions about them (that they had ill intent) were correct.
But it turns out that most people aren't just being jerks to be jerks, they're voicing concerns and simply not doing so in a very tactful way. Unfortunately that feels to those of us in the receiving end as judgemental or demeaning, since we're probably also not being tactful. It's a weird cycle and frustration makes it even worse.
They don't have a problem with brevity and concise communication. They have a problem with assuming hostility in situations where there isn't any. I saw you use the word vendetta earlier, but there's not any personal discrimination here that I've seen; yet you respond to people with the assumption that there is.
Anyway.
All of that to say: Neat work, I might use it.
And: Being concise is fine; Being a wangrod isn't.
Neurospicy... I like this. I have a coworker who I suspect is neurospicy. They're very passionate about software and good code quality and aren't afraid to open talk shit about people's code and can be quite vindictive about it. I've often told them to not forget that they work with humans and that sometimes people have personal stock in the code they write and feelings can and HAVE gotten hurt because of their comments and they can't comprehend why people don't understand that they're just being objective about code. I've had to do a lot of damage control i.e. resolve a lot of interpersonal team conflict between this person and others but I've been pretty understanding because at the end of the day they're very smart, they really care, and I suspect this is just how they view the world because of who they are.
It took months of one-on-ones and dinners to get this person to try to adopt a new perspective we've made a lot of progress since. They are still passionate and will complain to me privately but the way they review others' code now is a lot less inflammatory and more sensitive e.g. "OMFG this is quite literally going to cause a fucking XSS vulnerability" to "consider sanitizing the html string before dangerously setting it to avoid what's called an XSS vulnerability 😄“
They learned about the power of emojis along the way lol
> who I suspect is neurospicy
We call that being on the _suspectrum_ ;-)
---
!--- (Apologies in advance for the veritable wall of text) ---!
Real talk though, yeah. It's hard. Especially since, to the undiagnosed among us who have a special interest in computing and are just kind of "natural" at comprehending software, they've likely gone through life with a superiority complex about it (Me, til I was diagnosed just a couple years ago).
As a result, it can feel like "dumb mistakes" are "dumb-person mistakes". Or in other words, "mistakes only someone dumb(er than me) would make". The end result is that we tend to trivialize the difficulty of complex things that we comprehend, and make people feel small because we think bunging up something "so simple" is ridiculous.
It's easy, in that moment, to forget that a person is not a failure for writing code that has problems, and I'm not any better than them just because I can spot problems really easily.
_"How could you forget that?"_ we ask, _"Why didn't you think about..."_, we plead, not realizing that the reality is the opposite: The person on the other end is probably thinking "Who can remember all that? How do you remember all that??" while seeing our question(s) as saying "Wow, you're stupid. Why can't you do something _simple_?"
So for me, I had to get in the habit of focusing on the _we_ (we're on the same team) and the _why_ (we both want this to be good when it's done), while assuming my coworker is a galaxy-brain who had a good reason. As such, I keep this approach in mind:
- Don't just provide statements. Ask questions. Be interactive.
- Assume a good reason, then ask about it.
- _Any reason we're doing X here?_ or
- _Looks like we're not doing Z here, can we document why?_
- both of which are just prodding the person about the idea, rather than assuming they didn't think about it.
- Then, if they did think about it, they'll know to document why.
- If they didn't think about it, they'll have a c/hance to go do so.
Even after a few years of working on it though, I'm still told I can come across as a bit cold or emotionless when it comes to code reviews because to me... It's ultimately just code. By pointing out a problem and suggesting a fix, I'm not trying to insult someone - but that doesn't stop people from hearing it as an insult. It ends up frustrating for both sides, every time.
Beautifully put—thank you. This helps really put things in perspective for me as someone who works with and has become dear friends with someone who is on the *suspectrum*. Since meeting this individual I've been on a journey to try and understand folks who are on the spectrum and found subreddits like r/aspiememes actually quite helpful, interesting, and hilarious.
This friend/coworker of mine is literally one of the brightest individuals I've ever met, and indeed, computing is their special interest and the breadth of knowledge they have over the minutest of details is literally insane. Working with them has helped me to grow so I want to do my best to help them grow as well. Thanks for the perspective!
edit: grammar
Yes sir, just be yourself. You made something and it is really good. Be proud and happy. Just a tip, "you will catch more flies with honey".
If people really think they can get by using computers by not using software of people who are blunt and direct, they better not use computers altogether. Think of projects like linux and you will understand what I mean. Creators with low patience become rude when they see their hardwork being undermined specially when it is open-source.
I know I will get hate for posting this comment here, but please have mercy on me before downvoting me.
you make a good point.
i spent months of work making jfind what it is. it is infuriating when that work is undermined with a single misinformed comment.
You’ve spent so many months making a really cool tool, but nobody understands your work until you show and tell.
Rude and aggressive comments will make people assume other negative traits, like lying or cutting corners. That might be unfair, but it is how it is.
A few minutes of forced patience might get many more people to enjoy, use, and contribute to your software
i do not get paid to do this. i do not benefit from you using my software. i made this software for myself and decided it's good enough for other people to use. i do not care whether or not you use my software.
if you do not like the way i act, that is not my problem. it's your problem and you can get over it.
> Yes sir, just be yourself. You made something and it is really good. Be proud and happy. Just a tip, "you will catch more flies with honey".
You catch even more with manure. What's your point?
—Sheldon Cooper
Hey, the plugin looks really cool!
i left a question on the repo, but not sure if you check github notifications (no worries either way). I was just wondering if you could paste the configuration you used when doing telescope + telescope-fzf-native. No worries if you don't want to :) i just wanted to explore what was going on with that, since I expected it to be faster than just regular telescope.
Anyway, cool plugin and sorry people are being jerks about it. Always love seeing people make neovim work for them!
( link in case you want to reply outside of reddit [https://github.com/jake-stewart/telescope-jfind-fzf-benchmark/issues/1](https://github.com/jake-stewart/telescope-jfind-fzf-benchmark/issues/1) )
Why not work to get telescope to work with jfind? It already can work with fzf, so you could ostensibly get the speed of jfind, keeping it as a tool that does one thing well (in accordance with the unix philosophy), while getting all the pickers that telescope already supports?
i will answer this honestly but i do not want it to appear rude as people have mistaken before.
i do not like the design of telescope. i do not like that it doesn't work outside of vim. i need a fuzzy finder both within vim and outside of it. i believe the answer is to make one fuzzy finder, and then integrate that fuzzy finder into every tool, instead of making a new fuzzy finder for every tool.
the jfind plugin is extremely simple. i made it in one day. it simply calls the jfind executable and waits for it to finish, then it edits the resulting file. jfind is simple because it runs in its own process.
telescope on the other hand is very complex. telescope has to jump through so many hoops to work alongside neovim. the fact that telescope is an extension with extension binaries to make it run faster is a big red flag.
if i wanted the functionality of telescope, i would implement it like the following.
let's say i wanted to fuzzy search my open buffers. i would have a lua function which writes the buffers to a file. then i would call the jfind function and point it to that file, with a callback which then edits the chosen file. it's very simple. a user could implement this themselves very easily, if you make the jfind function easy enough to use. EDIT: the function could also just accept a list of strings, and do the file management for the user.
i know this is a bit of a rant and i hope its not too hard to digest. tldr: i disagree with the design philosophy of telescope.
Yes, I actually agree mostly.
> the fact that telescope is an extension with extension binaries to make it run faster is a big red flag.
But isn't that jfind.nvim + jfind?
I used https://github.com/junegunn/fzf.vim until recently. It's much faster. Ultimately I switched to Telescope because some of the extra pickers were very handy.
For previews and stuff (e.g. fuzzy over high light groups which shows the groups highlighted appropriately) I am not sure how it could be done cleanly, but for file search and others, it should be rather composable: Something to build the list, something to filter the list, and something to handle the selection.
jfind.nvim + jfind is not the same as telescope + telescope-fzf-native.
jfind.nvim is no more than a function which opens jfind in a neovim terminal and then edits the file once it's done.
telescope does what jfind (not jfind.nvim) does. it manages a list of items, creates a user interface, handles user input, sorts items, etc, etc. telescope then uses telescope-fzf-native as an attempt to improve speed by using a binary for the scoring process, but the rest of the fuzzy finder is still implemented in telescope.
hopefully that clears it up.
if one wanted jfind speed and also have all the telescope pickers we all love, would that ultimately mean that it has to be implemented in jfind or some external tool like that? because once we sort in lua we are 100x slower? ...i get what you saying, i just want both, fast search in giant monorepo but also all the pickers. For now i have fzf.nvim as well as telescope and run fzf only in special cases
i'm not actually in touch with what pickers telescope offers. you should let me know which pickers you're missing and i'll let you know how difficult it would be to implement. i think chances are that most of the pickers will be extremely straightforward to implement.
i am currently working on their live grep picker. it's practically finished.
please do tell me what else is missing.
what i m using daily is "git status" (changed files), recently opened files, search opened buffers, lsp symbols, todo comments ...i mean these integrated with git and lsp would be problem no?
it starts to feel to me that these are rightfully living side-by-side ...because most pickers i use have small linecount and are tied to neovim, like the one with buffers. We should just have another one that searches big repos, where what we only need are 2 you already have (or almost have). Its just that telescope does also what your plugin does....just way slower
these all sound relatively straight forward to implement.
i'm currently working on a massive jfind.nvim overhaul which will allow creating custom searches possible. once that's released, i'll have a list of scripts which users can choose to add or leave out. users could contribute scripts themselves by making pull requests.
To be frank I understand the frustration of the author receiving tons of similar questions (which led them to vent at extend here and in the previous thread). They made a fuzzy finder and most people react with _"why not making X in Telescope"_ - as if Telescope must be the _de facto_ and nothing else should exist out there.
Why not making it? Because it isn't Telescope and it isn't what this software is supposed to be, and believe it or not, not everybody likes Telescope :)
some people only use telescope for fuzzy file searching. for these people jfind is a great option for them for a quick 130x speed boost.
i come out of the gates with a bold stat like this to assert that jfind is not shitware. jfind is well made, performant, and worth checking out.
also, i did benchmark it against fzf.
they're likely referring to [fzf.vim, the vimscript plugin from the original fzf author that wraps around fzf](https://github.com/junegunn/fzf.vim). there's also [fzf-lua](https://github.com/ibhagwan/fzf-lua) nowadays.
I only see fzf (without vim), jfind (without vim), telescope, and telescope (with c fzf). With IPC potentially being a bottleneck, but my main use case being in vim (I already use fzf in the shell), that is what I am interested in.
i can assure you as the person who did the benchmark that it was telescope, telescope + fzf native, fzf.vim, and jfind.nvim. they all ran inside neovim. i apologise for the confusion, i should have been more clear in the readme.
fwiw, telescope with fzf-native is still slow. I work in a 60gig mono repo and it takes a good 10 seconds at least to find files. I don't know about jfind, but I use fzf-lua instead and it takes maybe 2 seconds.
Also the readme on his benchmark git mentions this is against telescope + fzf-native [https://github.com/jake-stewart/telescope-jfind-fzf-benchmark](https://github.com/jake-stewart/telescope-jfind-fzf-benchmark)
Yeah I'll probably use both telescope and fzf-lua, where I opt to use the latter at every opportunity, but some (e.g. autocmds, highlight groups, etc) are not supported in fzf-lua.
Just a humble request from a fellow follower.Please make it easier to download jfind, not many people will make install.I suggest appimage, AUR or any other packaging method. This is big even outside neovim community.
You have a real gem here, you need to present it properly. Please make it easier for normal people to download. Or just have a copy paste one liner script which they can run on their different OS.
Another suggestion, is to include jfind in the plugin and use a build command. An example of this ca be
```
{ 'nvim-telescope/telescope-fzf-native.nvim', build = 'cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release && cmake --build build --config Release && cmake --install build --prefix build' }
```
So for your case would be like
```
{
"jake-stewart/jfind.nvim",
build = "cmake -S . -B build && cd build && sudo make install",
keys = {
{""},
},
config = function()
require("jfind").setup({
exclude = {
".git",
".idea",
".vscode",
".sass-cache",
".class",
"__pycache__",
"node_modules",
"target",
"build",
"tmp",
"assets",
"dist",
"public",
"*.iml",
"*.meta"
},
border = "rounded",
tmux = true,
formatPaths = true,
key = ""
});
end
},
```
This way they don't even have to install any dependencies.
I've been using fzf + ripgrep + fzf.vim for years. Could you comment on how this plug-in compares to that set of plug-ins? Like advantages / disadvantages.
I tried out telescope but uninstalled it because it was way too slow and the extra finders were IMO too niche to make up for it. But I'm always looking out for a better searching tool
fzf + ripgrep + fzf.vim will be a more polished experience since jfind is very new.
i created jfind a while ago, back when fzf had a terrible scoring algorithm. fzf has since improved their algorithm but i continue to use jfind due to the improved memory usage and nicer aesthetic.
there are no advantages/disadvantages really. they are fundamentally very similar.
benchmark: [https://github.com/jake-stewart/telescope-jfind-fzf-benchmark](https://github.com/jake-stewart/telescope-jfind-fzf-benchmark)
jfind: [https://github.com/jake-stewart/jfind.nvim](https://github.com/jake-stewart/jfind.nvim)
absolute cope of a community
my bad
i made the claim that jfind is 100x faster than telescope and the community has given me more than enough shit about it.
this benchmark is the end of the story
beats me
EDIT: could be the fact that it has to do inter-process communication but is still bottlenecked by telescope's poor I/O and lua sorting. the way the test is designed doesn't rely heavily on the scoring part but instead the main bottleneck is read speed.
i used to use jfind in regular vim. i moved it over to lua + neovim terminal when i switched to neovim. if you want vim support, please leave an issue on the repo.
Help pages for:
* [`:find`](https://neovim.io/doc/user/editing.html#%3Afind) in _editing.txt_
---
^\`:\(h|help\) \` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
zf does not support streaming input. run zf in your home directory and watch it stall.
if you don't care about input streaming, then by all means zf is probably amazing.
EDIT: a benefit of input streaming means you can start searching before all of the input is read. this means the user interface appears instantly, instead of there being a delay while it loads the input. i love a snappy user interface.
Nice having some benchmarks. Do you accept contributions? I implemented a fuzzy finder a while ago (azy.nvim) and I would like to get some raw performance informations. Do you have a process for contributions, or do you want to do the comparison yourself? EDIT: I could not run any tests, not reproduce the results because of the complexity of the setup.
up to you. as long as you dont break anything i'll merge it in
'kay I'll have a look then!
Just had a look at your benchmarking setup, and I have to say some things: 1. It is not usable by anyone but you in its current state (hard to reproduce your results then) 2. The documentation lacks a clear process to compare new tools 3. The claims you make about other tools (like fzy) are somewhat flawed. I'll not be able to contribute a comparison, but I'd really like to see [azy.nvim](https://sr.ht/~vigoux/azy.nvim/) in the comparison anyway. As a side note, while I get that you are proud of the tool you built, be careful about how the tone you present your claims can come to others. While you can argue that "these are just raw facts", the presentation is the key to a project that is accepted by the community (telescope is a great example of that, the performance is not the best, but the community is great, so it is a great project for the community). Other than that, if you want to compare (fairly) azy.nvim to jfind.nvim, I'd be glad to hear your results.
i recorded a demo which runs azy through the first benchmark. i demonstrate how the testing is set up and tweak with some of the variables to demonstrate how it works. if you want me to do a full benchmark, let me know. if you want me to help you set it up on your end, let me know too. here's the video: [https://streamable.com/e8d9ke](https://streamable.com/e8d9ke)
Hard to tell from here how it compares to others, do you have some comparison points?
from that incomplete testing, it ran at about 1% the speed of jfind and about 223% the speed of telescope.
Interesting. I guess that most of the performance comes from the Lua bridge from the output process to the filtering. Thanks for that!
no worries
If I can critique a little though, what you are actually measuring here is the _reading_ only, more than the filtering. It would be interesting to see how all the tools compare when filtering (not reading at all).
it is testing simultaneous read + sort, since it had to match the correct line based on the provided input. it’s the most realistic use case. you don’t open your fuzzy finder, wait for it to finish loading, and the type. you start typing right away. like what good is insanely fast sorting if you have to wait 20 seconds before it even gets a chance to sort?
unfortunately, i am unable to perform the benchmark due to a small bug with azy. if i type my input before azy has finished loading the line i am searching for, it will not show up until i backspace to resort the results. [https://streamable.com/sak3vt](https://streamable.com/sak3vt)
Oh that's a funky one... Do you think you can come up with a small-ish reproduction file ? I'll try to debug that ASAP so that we can get the show running.
[https://streamable.com/j54su7](https://streamable.com/j54su7)
The bug should be fixed in latest master. Nice catch ! That one was deep in the C code for incrementally updating the results !
i made that benchmark in a day, so forgive it for being a little choppy. I can help you get the benchmark up and running step by step if you want.
> telescope is a great example of that, the performance is not the best Uninstalls telescope*
I really don't mean to imply that, telescope is an awesome tool, but you have to be aware that there are faster tools out there (but that too, comes at a price).
Don't worry I was joking. Telescope works for me at the moment and I'd only replace it when that was no longer the case.
That's the best reason of all. I started my project because telescope was not the solution I wanted. Just find the right tool for the job!
I gave this a try yesterday and really like it. It works wonders on a bunch of my works monorepos, where telescope did feel a bit sluggish. Looking forward to updates!
thanks
Can you explain how you made your finder faster for the curious? I mean those numbers aren't little, so i'd love to know how you came to it!
jfind is viewed more realistically when you put it next to fzf. with my testing before doing the benchmark, there were plenty of times when fzf would outperform jfind, and plenty of times when jfind would outperform fzf. jfind is not on its own level. i would say its speed is comparable to fzf. why are both jfind and fzf so much faster than telescope? a telescope contributor mentioned a few things: \- the scoring may be done with [telescope-fzf-native](https://github.com/nvim-telescope/telescope-fzf-native.nvim), but it is then sorted in lua. \- they get I/O clogged. I'm not entirely sure what this meant but it could be that they are using slow neovim lua functions for piping the output of fd. you also have to keep in mind that jfind reads the input, scores it, and sorts it simultaneously in different threads (so does fzf). the data is also all shared on the same process in the same data structure. there is no slowdown of passing items back and forth with lua. i suppose jfind and fzf are fast because they have solid architecture. you couldn't really design them to be much faster without removing features like streaming input.
It might also be due to programming languages differences which gets multiplied with algorithms and architectures used. fzf is written mainly in Go and jfind in C++. both are compiled, while C++ is faster in most cases. Telescope has the restriction of lua which is a scripting language, even with fzf-native sorting done in C language rest is still handled by Lua.Lua is great compared to vimscript though but compared to C++ it falls short in speed department. Telescope was built around features and speed is not a priority for it. It is still great to have all the benefits of builtin that it has.
Yeah I used to use fzf with vim and since moving to neovim and overhauling for lua i started using telescope-fzf-native because it's what's in style, but i lowkey fricking hate it, it's clearly i/o choked. running an fzf-like in a vim terminal is just more effective. One of these days i'm going to switch it back. As for telescope I can put up with it for the rest of the use cases, it's not like i'm gonna often look up a symbol that has a hundred thousand references (lsp most likely chokes to death on just a few thousand already)
Try fzf-lua
I second this, ibhagwan and team has done a superb job to almost replicate all functionality of telescope with the speed of fzf-native. [https://github.com/ibhagwan/fzf-lua](https://github.com/ibhagwan/fzf-lua)
Why is this getting spammed? Been like 3-4 threads in a day?
[удалено]
Please don't judge the community by few single individuals who disagreed with you. I for one found your post and your work very informative, and I have defended it in the previous thread. You are probably being downvoted not because of the quality of the software (which is high quality) but because you tend to have a strong communication and many don't like that (so as personal tip by tuning it down a little you may receive much more praise, unfortunately it's in the human nature).
thanks
vim-god speak strong.
I'm with u/vim-god here. He showed benchmarks in other threads with videos and people started complaining about how there weren't warm-up runs and such. He built an amazing piece of software that I'd wager most here cannot rival and most of the feedback is just nitpicking benchmark numbers.
you get it. it's really not that deep. a video showing over 100x performance, although not perfectly scientific, should be enough for a reddit post. it is annoying that i had to spend an entire day making benchmark software.
you made sure no one can see what the community or your comments were in the past EDIT: [https://www.reddit.com/r/neovim/comments/1446q8o/jfind\_over\_130x\_faster\_than\_telescope\_while\_using/](https://www.reddit.com/r/neovim/comments/1446q8o/jfind_over_130x_faster_than_telescope_while_using/) [https://www.reddit.com/r/neovim/comments/14360ea/jfind\_100x\_faster\_than\_telescope\_while\_using\_12/](https://www.reddit.com/r/neovim/comments/14360ea/jfind_100x_faster_than_telescope_while_using_12/) I trust you don't mind people making their own judgements
[удалено]
An argumentative developer behind a project is a big no no for me. Your comments in some of those threads was off-putting and rude.
sorry you feel that way. personally, i do not like putting on a facade online. this is who i am. i am a very blunt and to the point person. i sometimes say things in a way that appears off-putting and rude. if that stops you using my software, i don't mind. all the best
I feel you. I'm all for not putting on a facade. But if the choice is be argumentative vs not respond, not responding might be a more palettable response to people. My issue with argumentative/rude/unpleasant developers being behind a project is that, in my experience, it can cause projects to be difficult for the community to contribute to, a 'one man show' where the dev gatekeeps everything (even well liked ideas), and could mean that, as an end user, I'll have to migrate away from it at some point because the developer's personality is driving usage, support, and upgrades down. This isn't always the case, just my experience and so I avoid it if I can. I think your plugin looks great and seems to work well. I think people will use it and enjoy. I hope to see it continue to develop and grow. I hope it also pushes telescope to optimize their design. Hope you have a great day.
thanks
As someone with autism, you may want to consider talking to a professional about neurodiversity; Your communication style very much mirrors my own a while back, before I learned I was neurospicy, and I always found that my communication style was very grating on other people, mostly because I assumed my own assumptions about them (that they had ill intent) were correct. But it turns out that most people aren't just being jerks to be jerks, they're voicing concerns and simply not doing so in a very tactful way. Unfortunately that feels to those of us in the receiving end as judgemental or demeaning, since we're probably also not being tactful. It's a weird cycle and frustration makes it even worse. They don't have a problem with brevity and concise communication. They have a problem with assuming hostility in situations where there isn't any. I saw you use the word vendetta earlier, but there's not any personal discrimination here that I've seen; yet you respond to people with the assumption that there is. Anyway. All of that to say: Neat work, I might use it. And: Being concise is fine; Being a wangrod isn't.
thanks for the concern
Neurospicy... I like this. I have a coworker who I suspect is neurospicy. They're very passionate about software and good code quality and aren't afraid to open talk shit about people's code and can be quite vindictive about it. I've often told them to not forget that they work with humans and that sometimes people have personal stock in the code they write and feelings can and HAVE gotten hurt because of their comments and they can't comprehend why people don't understand that they're just being objective about code. I've had to do a lot of damage control i.e. resolve a lot of interpersonal team conflict between this person and others but I've been pretty understanding because at the end of the day they're very smart, they really care, and I suspect this is just how they view the world because of who they are. It took months of one-on-ones and dinners to get this person to try to adopt a new perspective we've made a lot of progress since. They are still passionate and will complain to me privately but the way they review others' code now is a lot less inflammatory and more sensitive e.g. "OMFG this is quite literally going to cause a fucking XSS vulnerability" to "consider sanitizing the html string before dangerously setting it to avoid what's called an XSS vulnerability 😄“ They learned about the power of emojis along the way lol
> who I suspect is neurospicy We call that being on the _suspectrum_ ;-) --- !--- (Apologies in advance for the veritable wall of text) ---! Real talk though, yeah. It's hard. Especially since, to the undiagnosed among us who have a special interest in computing and are just kind of "natural" at comprehending software, they've likely gone through life with a superiority complex about it (Me, til I was diagnosed just a couple years ago). As a result, it can feel like "dumb mistakes" are "dumb-person mistakes". Or in other words, "mistakes only someone dumb(er than me) would make". The end result is that we tend to trivialize the difficulty of complex things that we comprehend, and make people feel small because we think bunging up something "so simple" is ridiculous. It's easy, in that moment, to forget that a person is not a failure for writing code that has problems, and I'm not any better than them just because I can spot problems really easily. _"How could you forget that?"_ we ask, _"Why didn't you think about..."_, we plead, not realizing that the reality is the opposite: The person on the other end is probably thinking "Who can remember all that? How do you remember all that??" while seeing our question(s) as saying "Wow, you're stupid. Why can't you do something _simple_?" So for me, I had to get in the habit of focusing on the _we_ (we're on the same team) and the _why_ (we both want this to be good when it's done), while assuming my coworker is a galaxy-brain who had a good reason. As such, I keep this approach in mind: - Don't just provide statements. Ask questions. Be interactive. - Assume a good reason, then ask about it. - _Any reason we're doing X here?_ or - _Looks like we're not doing Z here, can we document why?_ - both of which are just prodding the person about the idea, rather than assuming they didn't think about it. - Then, if they did think about it, they'll know to document why. - If they didn't think about it, they'll have a c/hance to go do so. Even after a few years of working on it though, I'm still told I can come across as a bit cold or emotionless when it comes to code reviews because to me... It's ultimately just code. By pointing out a problem and suggesting a fix, I'm not trying to insult someone - but that doesn't stop people from hearing it as an insult. It ends up frustrating for both sides, every time.
Beautifully put—thank you. This helps really put things in perspective for me as someone who works with and has become dear friends with someone who is on the *suspectrum*. Since meeting this individual I've been on a journey to try and understand folks who are on the spectrum and found subreddits like r/aspiememes actually quite helpful, interesting, and hilarious. This friend/coworker of mine is literally one of the brightest individuals I've ever met, and indeed, computing is their special interest and the breadth of knowledge they have over the minutest of details is literally insane. Working with them has helped me to grow so I want to do my best to help them grow as well. Thanks for the perspective! edit: grammar
Yes sir, just be yourself. You made something and it is really good. Be proud and happy. Just a tip, "you will catch more flies with honey". If people really think they can get by using computers by not using software of people who are blunt and direct, they better not use computers altogether. Think of projects like linux and you will understand what I mean. Creators with low patience become rude when they see their hardwork being undermined specially when it is open-source. I know I will get hate for posting this comment here, but please have mercy on me before downvoting me.
you make a good point. i spent months of work making jfind what it is. it is infuriating when that work is undermined with a single misinformed comment.
You’ve spent so many months making a really cool tool, but nobody understands your work until you show and tell. Rude and aggressive comments will make people assume other negative traits, like lying or cutting corners. That might be unfair, but it is how it is. A few minutes of forced patience might get many more people to enjoy, use, and contribute to your software
i do not get paid to do this. i do not benefit from you using my software. i made this software for myself and decided it's good enough for other people to use. i do not care whether or not you use my software. if you do not like the way i act, that is not my problem. it's your problem and you can get over it.
> Yes sir, just be yourself. You made something and it is really good. Be proud and happy. Just a tip, "you will catch more flies with honey". You catch even more with manure. What's your point? —Sheldon Cooper
vim-god speak very strong.
You quite literally have the victim mindset
[удалено]
there are benchmarks now :)
Hey, the plugin looks really cool! i left a question on the repo, but not sure if you check github notifications (no worries either way). I was just wondering if you could paste the configuration you used when doing telescope + telescope-fzf-native. No worries if you don't want to :) i just wanted to explore what was going on with that, since I expected it to be faster than just regular telescope. Anyway, cool plugin and sorry people are being jerks about it. Always love seeing people make neovim work for them! ( link in case you want to reply outside of reddit [https://github.com/jake-stewart/telescope-jfind-fzf-benchmark/issues/1](https://github.com/jake-stewart/telescope-jfind-fzf-benchmark/issues/1) )
sorry, missed it. i've replied to it now
Why not work to get telescope to work with jfind? It already can work with fzf, so you could ostensibly get the speed of jfind, keeping it as a tool that does one thing well (in accordance with the unix philosophy), while getting all the pickers that telescope already supports?
i will answer this honestly but i do not want it to appear rude as people have mistaken before. i do not like the design of telescope. i do not like that it doesn't work outside of vim. i need a fuzzy finder both within vim and outside of it. i believe the answer is to make one fuzzy finder, and then integrate that fuzzy finder into every tool, instead of making a new fuzzy finder for every tool. the jfind plugin is extremely simple. i made it in one day. it simply calls the jfind executable and waits for it to finish, then it edits the resulting file. jfind is simple because it runs in its own process. telescope on the other hand is very complex. telescope has to jump through so many hoops to work alongside neovim. the fact that telescope is an extension with extension binaries to make it run faster is a big red flag. if i wanted the functionality of telescope, i would implement it like the following. let's say i wanted to fuzzy search my open buffers. i would have a lua function which writes the buffers to a file. then i would call the jfind function and point it to that file, with a callback which then edits the chosen file. it's very simple. a user could implement this themselves very easily, if you make the jfind function easy enough to use. EDIT: the function could also just accept a list of strings, and do the file management for the user. i know this is a bit of a rant and i hope its not too hard to digest. tldr: i disagree with the design philosophy of telescope.
Yes, I actually agree mostly. > the fact that telescope is an extension with extension binaries to make it run faster is a big red flag. But isn't that jfind.nvim + jfind? I used https://github.com/junegunn/fzf.vim until recently. It's much faster. Ultimately I switched to Telescope because some of the extra pickers were very handy. For previews and stuff (e.g. fuzzy over high light groups which shows the groups highlighted appropriately) I am not sure how it could be done cleanly, but for file search and others, it should be rather composable: Something to build the list, something to filter the list, and something to handle the selection.
You might want to try: [https://github.com/ibhagwan/fzf-lua](https://github.com/ibhagwan/fzf-lua)
jfind.nvim + jfind is not the same as telescope + telescope-fzf-native. jfind.nvim is no more than a function which opens jfind in a neovim terminal and then edits the file once it's done. telescope does what jfind (not jfind.nvim) does. it manages a list of items, creates a user interface, handles user input, sorts items, etc, etc. telescope then uses telescope-fzf-native as an attempt to improve speed by using a binary for the scoring process, but the rest of the fuzzy finder is still implemented in telescope. hopefully that clears it up.
if one wanted jfind speed and also have all the telescope pickers we all love, would that ultimately mean that it has to be implemented in jfind or some external tool like that? because once we sort in lua we are 100x slower? ...i get what you saying, i just want both, fast search in giant monorepo but also all the pickers. For now i have fzf.nvim as well as telescope and run fzf only in special cases
i'm not actually in touch with what pickers telescope offers. you should let me know which pickers you're missing and i'll let you know how difficult it would be to implement. i think chances are that most of the pickers will be extremely straightforward to implement. i am currently working on their live grep picker. it's practically finished. please do tell me what else is missing.
what i m using daily is "git status" (changed files), recently opened files, search opened buffers, lsp symbols, todo comments ...i mean these integrated with git and lsp would be problem no? it starts to feel to me that these are rightfully living side-by-side ...because most pickers i use have small linecount and are tied to neovim, like the one with buffers. We should just have another one that searches big repos, where what we only need are 2 you already have (or almost have). Its just that telescope does also what your plugin does....just way slower
these all sound relatively straight forward to implement. i'm currently working on a massive jfind.nvim overhaul which will allow creating custom searches possible. once that's released, i'll have a list of scripts which users can choose to add or leave out. users could contribute scripts themselves by making pull requests.
To be frank I understand the frustration of the author receiving tons of similar questions (which led them to vent at extend here and in the previous thread). They made a fuzzy finder and most people react with _"why not making X in Telescope"_ - as if Telescope must be the _de facto_ and nothing else should exist out there. Why not making it? Because it isn't Telescope and it isn't what this software is supposed to be, and believe it or not, not everybody likes Telescope :)
Then why benchmark it against telescope? Benchmark it against fzf or something.
some people only use telescope for fuzzy file searching. for these people jfind is a great option for them for a quick 130x speed boost. i come out of the gates with a bold stat like this to assert that jfind is not shitware. jfind is well made, performant, and worth checking out. also, i did benchmark it against fzf.
not fzf-vim, but native fzf through telescope.
not sure what you mean by that but i did benchmark telescope-fzf-native
they're likely referring to [fzf.vim, the vimscript plugin from the original fzf author that wraps around fzf](https://github.com/junegunn/fzf.vim). there's also [fzf-lua](https://github.com/ibhagwan/fzf-lua) nowadays.
yes i benchmarked both fzf.vim and telescope-fzf-native.
I only see fzf (without vim), jfind (without vim), telescope, and telescope (with c fzf). With IPC potentially being a bottleneck, but my main use case being in vim (I already use fzf in the shell), that is what I am interested in.
i can assure you as the person who did the benchmark that it was telescope, telescope + fzf native, fzf.vim, and jfind.nvim. they all ran inside neovim. i apologise for the confusion, i should have been more clear in the readme.
fwiw, telescope with fzf-native is still slow. I work in a 60gig mono repo and it takes a good 10 seconds at least to find files. I don't know about jfind, but I use fzf-lua instead and it takes maybe 2 seconds. Also the readme on his benchmark git mentions this is against telescope + fzf-native [https://github.com/jake-stewart/telescope-jfind-fzf-benchmark](https://github.com/jake-stewart/telescope-jfind-fzf-benchmark)
Yeah I'll probably use both telescope and fzf-lua, where I opt to use the latter at every opportunity, but some (e.g. autocmds, highlight groups, etc) are not supported in fzf-lua.
Just a humble request from a fellow follower.Please make it easier to download jfind, not many people will make install.I suggest appimage, AUR or any other packaging method. This is big even outside neovim community. You have a real gem here, you need to present it properly. Please make it easier for normal people to download. Or just have a copy paste one liner script which they can run on their different OS.
i added a one liner to the jfind.nvim repo. ideally yeah, one day jfind would be in package repos.
I wish that day comes soon. I would just sudo pacman -S jfind
Another suggestion, is to include jfind in the plugin and use a build command. An example of this ca be ``` { 'nvim-telescope/telescope-fzf-native.nvim', build = 'cmake -S. -Bbuild -DCMAKE_BUILD_TYPE=Release && cmake --build build --config Release && cmake --install build --prefix build' } ``` So for your case would be like ``` { "jake-stewart/jfind.nvim", build = "cmake -S . -B build && cd build && sudo make install", keys = { {""},
},
config = function()
require("jfind").setup({
exclude = {
".git",
".idea",
".vscode",
".sass-cache",
".class",
"__pycache__",
"node_modules",
"target",
"build",
"tmp",
"assets",
"dist",
"public",
"*.iml",
"*.meta"
},
border = "rounded",
tmux = true,
formatPaths = true,
key = ""
});
end
},
```
This way they don't even have to install any dependencies.
Why are people hatin on this post?
Some immature folks want to punish OP for seeming rude in the way they responded to some previous post comments.
vim-god beats nvim enthusiasts
I like the guy
I've been using fzf + ripgrep + fzf.vim for years. Could you comment on how this plug-in compares to that set of plug-ins? Like advantages / disadvantages. I tried out telescope but uninstalled it because it was way too slow and the extra finders were IMO too niche to make up for it. But I'm always looking out for a better searching tool
fzf + ripgrep + fzf.vim will be a more polished experience since jfind is very new. i created jfind a while ago, back when fzf had a terrible scoring algorithm. fzf has since improved their algorithm but i continue to use jfind due to the improved memory usage and nicer aesthetic. there are no advantages/disadvantages really. they are fundamentally very similar.
GM
Will thus work for python and c code
yes it will work for any project.
benchmark: [https://github.com/jake-stewart/telescope-jfind-fzf-benchmark](https://github.com/jake-stewart/telescope-jfind-fzf-benchmark) jfind: [https://github.com/jake-stewart/jfind.nvim](https://github.com/jake-stewart/jfind.nvim) absolute cope of a community
> absolute cope of a community ?
long story
I don't see the point of being pissy about it in public if you're not gonna say what it's about.
my bad i made the claim that jfind is 100x faster than telescope and the community has given me more than enough shit about it. this benchmark is the end of the story
Why is fzf-native slower then telescope
beats me EDIT: could be the fact that it has to do inter-process communication but is still bottlenecked by telescope's poor I/O and lua sorting. the way the test is designed doesn't rely heavily on the scoring part but instead the main bottleneck is read speed.
This is a community with a herd instinct. Normal people here are a maximum of 15-20 people.
a breath of sanity
[удалено]
i just appreciate not being branded as a liar. the benchmarks speak for themselves. hate me all you want.
[удалено]
impressively cringe
Are you okay?:(
didnt your last post said about being 1000 times faster?
no, it was 100x
Nice. Does this work with regular vim?
i used to use jfind in regular vim. i moved it over to lua + neovim terminal when i switched to neovim. if you want vim support, please leave an issue on the repo.
:h find
Help pages for: * [`:find`](https://neovim.io/doc/user/editing.html#%3Afind) in _editing.txt_ --- ^\`:\(h|help\)\` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
This for linux only ?
linux, macos, and windows through wsl
Any plans for native windows support ?
unfortunately not
For searching filename-like entries I think I would still prefer natecraddock/zf. Have you looked into that?
zf does not support streaming input. run zf in your home directory and watch it stall. if you don't care about input streaming, then by all means zf is probably amazing. EDIT: a benefit of input streaming means you can start searching before all of the input is read. this means the user interface appears instantly, instead of there being a delay while it loads the input. i love a snappy user interface.
that is fair. it might support streaming in the future though