Search for occurences of whole word.

[arogowie-intel]

Hi!

Thank you very much for this outstanding and powerful tool, which makes my life much easier and more productive! :) I'm using speedscope from some time and currently I have a feeling that its built-in search functionality is not searching for whole words, which is quite unusual for me. Seems to me that it's enough that the respective letters constituting the word I'm searching for are present to be counted as an occurrence.

How can I make the search engine to search for whole words? If that's not possible could you kindly add such feature please?

[jlfwong]

Hi @arogowie-intel!

Searching at the moment uses fuzzy matching, but should prioritize exact matches.

The tricky thing here is it may be prioritizing the "axpy" showing split up over the "AXPY" that's all together. If you search for "AXPY" instead, does that give you the ordering you'd expect?

[arogowie-intel]

Hi @jlfwong!

Right I could search with upper case for "AXPY" then it's better in this specific case, however mostly I search for lower case symbols. Actually what I would like to see is to not see any split letter matches like in the screenshot above. They're very distracting and obscure overall results.

Is there any possibility to get rid of those split matches?

If you could just point me out where search mechanism is I could give it a try to implement this.

[mhansen]

+1 to the feature request of being able to search non-fuzzily. I'm almost always searching for specific identifiers and the fuzziness gets in the way. For example when I'm searching for the method callActivityOn it matches this, in tiny one-character chunks:

> std::__1::__tree<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, unsigned long>, std::__1::__map_value_compare<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, unsigned long>, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, true>, std::__1::allocator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, unsigned long> > >::destroy(std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, unsigned long>, void*>*) (/apex/com.android.art/lib64/libart-compiler.so)

Thanks for speedscope, it's a cool tool. This just my 2c :-)

[adamsitnik]

As a workaround you can use the search provided by the web browser :

[osievert-gpfw]

Fuzzy-matching is nice in certain situations, but I typically know the exact contiguous characters I want to search for, and so my personal preference would be for the default search to only show exact-match results, but allow me to opt-in to fuzzy search when I want it. Perhaps my usage is atypical, but I want to see exact-match results a lot more often than I want to see fuzzy-match results. I was pleasantly surprised when cmd+F brought up a search bar in speedcope, just like every other app I use. But it was unexpected to me that no matter what I typed in the search bar, the search algorithm matched almost every event in my trace. In all the other apps I use, cmd+F performs an exact-match search, so that was my expectation coming into speedscope.

Specific examples of what I mean. If I search for "foo" in my trace then almost every trace event matches, even though the contiguous substring "foo" does not appear at all in the entire data set. Searching for the word "optional" in my trace (the specific use case that brought me to this ticket today) seemed like a pretty precise search to me, but this matched about 50% of all events in my trace, even though the contiguous substring "optional" only appears twice in the entire data set. The speedscope search bar failed me today - I couldn't actually find the two occurrences of the word "optional" because there were too many false positives in the search results.

fzf handles this by allowing the user to specify whether they want a fuzzy match or an exact match. By default fzf does fuzzy matching - that is its primary purpose in life, so it makes sense for fuzzy-match to be the default (makes more sense for fuzzy-match to be the default in fzf, makes less sense for fuzzy-match to be the default in speedscope IMO). But even though fzf's primary purpose is fuzzy search, it recognizes that exact-match is useful, and so in fzf if you prepend a tick (e.g., 'foo) to the search string that causes fzf to perform an exact-match search. Without adding a ton of complexity to the search UI in speedscope, exact-match searches could be supported using this kind of syntax.

Alternately, I could envision a speedscope search bar that combines regex (which was mentioned in passing in https://github.com/jlfwong/speedscope/issues/38), fuzzy, and exact match searching in a single syntax:

• foo does an exact-match search for the contiguous substring "foo" (default is exact-match)
• s/[fg]oo/ does a regex search for either "foo" or "goo"
• f/foo/ does a fuzzy-match search for things like "foo" Obviously, this approach makes fuzzy-match more cumbersome to type, but I think that is ok if fuzzy match is the less-common use case.

[bjorn3]

As a workaround you can use the search provided by the web browser :

I believe speedscope only loads what is actually visible and a bit more as html. If you got a long list of functions most will probably not be found by using the browser search functionality.

[AloisKraus]

I am also lost in the fuzzy search. Normally I would paste a method/class name to Speedscope to drill deeper from other profiling tools. Speedscope offers some nice visualization capabilities but it is not the only tool I am using. A simple checkbox to turn fuzzy off would be great for me. The browser search only searches the visible range which is of no help if I have many pages of method names to look after. This is especially bad if I want to search for the non existence of specific methods to verify that an issue is gone. This is currently impossible with fuzzy search. I am not sure how everyone else is usin g the UI but that should be a frequent use case? Or is everyone "just" optimizing the mount Everest method and be done with it?

Would it be hard to support pasting text into the Search Window? That should be a frequent use case. Why is this not working?

[jlfwong]

Hey all -- I'm curious if anyone actually uses the fuzzy search capabilities. I added it mostly out of instinct rather than anyone in particular asking for it, and it seems based on feedback it's caused more trouble than joy.

While I hear a lot of requests for adding a checkbox, I bias towards having an aversion to options except where absolutely needed, so I'd rather just remove the fuzzy search entirely unless I hear specific cries for it's continued existence.

[andreid-db]

Another alternative that I've seen work is using fuzzy matching only if letters are separated by " ". So for example "callActivity" would be exact match, "c a l l A c t i v i t y" would be the equivalent of what we have today, and "call Activity" would be somewhere in between.

It's not as powerful as regex matching, but might be easier to use.

[AloisKraus]

I am surprised that the fuzzy search is still there. No one excepts that when searching for something.

[jlfwong]

Hey, sorry I've been dragging my feet on this.

My personal inclination is to do neither regex nor fuzzy matching here. Just as some people are seeing surprising behaviour from fuzzy matching, there would be surprising behaviour from regex as well (e.g. if you search for com. to search for some java string, it'd match comp since the . would match anything). There are trickier things you could do here, but I think probably just scrapping it and going for exact substring match is best.

[cgkantidis]

Yes please remove the fuzzy searching. Or put it behind an option/setting. It's a great tool otherwise! Thank you very much!

[jlfwong]

Okay! Exact matching (no fuzzy matching, no regex) should be live on https://www.speedscope.app/ now and published as part of speedscope@1.15.0. Thank you all for you feedback.

I changed the behaviour for all Ctrl/Cmd+F behaviour to use exact match, but I left profile selection (in the case of multithreaded or multiprocess profiles) to keep using fuzzy matching. My hope is that it's more useful there, and the fuzzy matching scoring in that case should still prioritize exact matches.

[cgkantidis]

Thanks! I can confirm it works as expected now!