3 ms·

Alright, so initial testing result. I'm not going to even bother putting into excel, RipGrep blew the hell out of Powershells built in stuff. Like, we're talkin

by maldev 4y ago

Alright, so initial testing result. I'm not going to even bother putting into excel, RipGrep blew the hell out of Powershells built in stuff. Like, we're talking exponentially quicker, so well done. (3 minutes for Pwsh vs 2 seconds Ripgrep) But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side, and very good coding on your side. And since I have to make up 12 hours tomorrow at work, but have zero tickets. I'll probably go in and write a Grep utility in C# and I think I can get similar speed to the Rust implementation. C# is also cross platform as of a couple years ago, as well as is powershell. So my testing was running Powershell on linux against the newest linux kernel source code + the build artifacts.

majkinetor 4y ago
You can't compare rg with other full RE engines. Try to repeat the test by switching its regex engine to use PCRE2 ( --pcre2 ).
- burntsushi 4y ago
  What? Can you say more? In many cases, ripgrep's speed is due in part to integrations with the default regex engine that don't happen with PCRE2.
  - majkinetor 4y ago
    Why would you compare C#/pwsh PCRE with somethign that is not PCRE and hence has different features. Compare with rg that has --pcre option set if you want to get real comparison.
    - burntsushi 4y ago
      Why wouldn't you? The other poster hasn't even said which regex engine or which tool they're measuring. PCRE is absolutely a competitor to Rust's regex crate and it makes sense to compare them. If all you're doing is measuring the time it takes to find `foo` or `\w+_foo`, then the specific regex engine being used is just an implementation detail. I'm not saying that using --pcre2 is wrong. It is certainly a useful comparison. But using the default regex engine when the task is "measure a grep" is certainly not wrong either.
burntsushi 4y ago
I think you've kind of already moved the goal posts. Your original comment spoke as if it were factual. But now you're saying "I think it can be done." But you don't know. And on top of that, there have been many greps written in a variety of languages: Go, Python, Perl, Ruby. All of them, that I've tested, are slower than most greps written in C, C++ and Rust. (In some cases, the greps written in Go can be quite fast, but they have very steep performance cliffs that are easy to trip over.) There are very good reasons to explain this state of affairs. C# is not something I have a lot of experience with. I don't spend time with Windows-only technologies. C# may technically work on Linux these days, but I don't know of any popular general purpose CLI tooling built with it that works on Unix systems. Why is that? My suspicion is that there are good reasons for it. But if there aren't, then there is a market opening waiting for folks to plow forward. Basically, I think you are wrong on multiple levels. I think you both under-estimate the difficulty of writing a fast grep and what exactly it takes to do it, and I think you're completely wrong about when Rust is useful. You completely neglect the safety aspect of it, and seem to believe it is not on even footing with C or C++ when it comes to performance. But it most certainly is, in general. > But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side Making baseless assertions feels like a pattern that is forming in your comments. Where is Redmond's code? Can you read it and link to me the parts that are "poor"? If not, from whence comes the accusation? And if you insist with your interpretation of reality, then it follows that I therefore must be a good coder. And if a good coder says to you, "I do not know how to write a fast grep in Go, Python, Perl or Ruby," then why don't you take them seriously?
- maldev 4y ago
  You keep seeming to come back to "needing the source code.". You know you can reverse engineer a program extremely easily right? Especially a C# one? It's really not the gotcha you think it is. And you can easily see from heuristics that it shouldn't take nearly a minute to gather all the filenames from subdirectories as with GCI. Doesn't take an Einstein to do that. As for the safety aspect. Can you tell me what Rust means by "Safety"? Alot of Rustacians throw it out, but it really only means "No Undefined behavior". It can help hint at issues, but as someone who writes C code day in and day out, a proper coding technique like SESE can prevent all the issues Rust prevents, and a Static Analyzer like SAL goes far and beyond it. And then with all the icky runtime checks Rust adds, you can't get that in the Kernel, you can't get that "for free". And speaking of reversing your code, it throws in your path names, your file names, and information about the code into each of these. It's definitely not safe opsec wise for a dissident in a dicatorship or an activist! You also seem to claim C# is "Windows only". Neither C#, nor Powershell, are "Windows Only". C# can run on just the same targets Rust can. WASM, Linux, Windows, etc. You said I wasn't talking about things I was knowledgable on, but despite multiple "hints" on that it's not "Windows Only", you don't seem to want to accept that. It's been the case for years. Being that stale with tech would be retire or fire territory, or just an indicator of incompetence. And I never said you were a good coder, I said you did a decent job writing RipGrep based off of performance. I personally think from your comments that you have a very small amount of experience with Language design or low level programming, and would not hire you and would put in my review "Does not take hints, is very rude and stubborn." You call my claims baseless, I went and did testing on the PS commandlets and said they were not fast. I have a program i'm testing right now which matches RG in performance. I'm going to name it "RipGrep But Not Ass". I'll have it on github for you whenever I get the time to finish it. Then you can "Analyze the source code". This conversation is dumb, and you are honestly one of the worst people i've encountered in the coding community.

by maldev 4y ago

majkinetor 4y ago

You can't compare rg with other full RE engines. Try to repeat the test by switching its regex engine to use PCRE2 ( --pcre2 ).

burntsushi 4y ago
What? Can you say more? In many cases, ripgrep's speed is due in part to integrations with the default regex engine that don't happen with PCRE2.
- majkinetor 4y ago
  Why would you compare C#/pwsh PCRE with somethign that is not PCRE and hence has different features. Compare with rg that has --pcre option set if you want to get real comparison.
  - burntsushi 4y ago
    Why wouldn't you? The other poster hasn't even said which regex engine or which tool they're measuring. PCRE is absolutely a competitor to Rust's regex crate and it makes sense to compare them. If all you're doing is measuring the time it takes to find `foo` or `\w+_foo`, then the specific regex engine being used is just an implementation detail. I'm not saying that using --pcre2 is wrong. It is certainly a useful comparison. But using the default regex engine when the task is "measure a grep" is certainly not wrong either.

burntsushi 4y ago

I think you've kind of already moved the goal posts. Your original comment spoke as if it were factual. But now you're saying "I think it can be done." But you don't know. And on top of that, there have been many greps written in a variety of languages: Go, Python, Perl, Ruby. All of them, that I've tested, are slower than most greps written in C, C++ and Rust. (In some cases, the greps written in Go can be quite fast, but they have very steep performance cliffs that are easy to trip over.) There are very good reasons to explain this state of affairs. C# is not something I have a lot of experience with. I don't spend time with Windows-only technologies. C# may technically work on Linux these days, but I don't know of any popular general purpose CLI tooling built with it that works on Unix systems. Why is that? My suspicion is that there are good reasons for it. But if there aren't, then there is a market opening waiting for folks to plow forward. Basically, I think you are wrong on multiple levels. I think you both under-estimate the difficulty of writing a fast grep and what exactly it takes to do it, and I think you're completely wrong about when Rust is useful. You completely neglect the safety aspect of it, and seem to believe it is not on even footing with C or C++ when it comes to performance. But it most certainly is, in general. > But I don't think it's the fault of C# and I think it's the fault of some poor coding on redmonds side Making baseless assertions feels like a pattern that is forming in your comments. Where is Redmond's code? Can you read it and link to me the parts that are "poor"? If not, from whence comes the accusation? And if you insist with your interpretation of reality, then it follows that I therefore must be a good coder. And if a good coder says to you, "I do not know how to write a fast grep in Go, Python, Perl or Ruby," then why don't you take them seriously?

maldev 4y ago
You keep seeming to come back to "needing the source code.". You know you can reverse engineer a program extremely easily right? Especially a C# one? It's really not the gotcha you think it is. And you can easily see from heuristics that it shouldn't take nearly a minute to gather all the filenames from subdirectories as with GCI. Doesn't take an Einstein to do that. As for the safety aspect. Can you tell me what Rust means by "Safety"? Alot of Rustacians throw it out, but it really only means "No Undefined behavior". It can help hint at issues, but as someone who writes C code day in and day out, a proper coding technique like SESE can prevent all the issues Rust prevents, and a Static Analyzer like SAL goes far and beyond it. And then with all the icky runtime checks Rust adds, you can't get that in the Kernel, you can't get that "for free". And speaking of reversing your code, it throws in your path names, your file names, and information about the code into each of these. It's definitely not safe opsec wise for a dissident in a dicatorship or an activist! You also seem to claim C# is "Windows only". Neither C#, nor Powershell, are "Windows Only". C# can run on just the same targets Rust can. WASM, Linux, Windows, etc. You said I wasn't talking about things I was knowledgable on, but despite multiple "hints" on that it's not "Windows Only", you don't seem to want to accept that. It's been the case for years. Being that stale with tech would be retire or fire territory, or just an indicator of incompetence. And I never said you were a good coder, I said you did a decent job writing RipGrep based off of performance. I personally think from your comments that you have a very small amount of experience with Language design or low level programming, and would not hire you and would put in my review "Does not take hints, is very rude and stubborn." You call my claims baseless, I went and did testing on the PS commandlets and said they were not fast. I have a program i'm testing right now which matches RG in performance. I'm going to name it "RipGrep But Not Ass". I'll have it on github for you whenever I get the time to finish it. Then you can "Analyze the source code". This conversation is dumb, and you are honestly one of the worst people i've encountered in the coding community.