8 ms·

While reading this my hope was it not being written in JavaScript. I'm not disappointed ;)

by hwj 8y ago

weavie 8y ago
261 lines of pure Rust by the look of it.
dancek 8y ago
I was hoping that it's written in Rust. I wasn't disappointed either.
ConcernedCoder 8y ago
Yeah! -- Because prejudice rocks and JavaScript sucks right?
- neysofu 8y ago
  Every problem requires appropriate tools. Why would you use a slow and resource-intensive language for a thing as simple as hex viewing?
pantalaimon 8y ago
It's comparably slow though :p xxd `which hexyl` > /dev/null 0.12s user 0.09s system 99% cpu 0.219 total hexdump `which hexyl` > /dev/null 0.19s user 0.05s system 91% cpu 0.256 total hexyl `which hexyl` > /dev/null 1.69s user 0.39s system 95% cpu 2.175 total
- sgt 8y ago
  It takes a second to compute all that color. Nice tool though - but what I would really like to see is a --color argument added to xxd as well, as I'll probably forget about hexyl down the line and start looking for xxd again (which is conveniently already installed on most *nix systems).
- ByronBates 8y ago
  The same author also wrote hyperfine, a tool to compare performance of various program runs. hyperfine './target/release/hexyl ./target/release/hexyl' 'xxd ./target/release/hexyl' 'hexdump ./target/release/hexyl' Benchmark #1: ./target/release/hexyl ./target/release/hexyl Time (mean ± σ): 1.529 s ± 0.028 s [User: 1.476 s, System: 0.050 s] Range (min … max): 1.491 s … 1.581 s 10 runs Benchmark #2: xxd ./target/release/hexyl Time (mean ± σ): 70.5 ms ± 0.5 ms [User: 68.0 ms, System: 1.2 ms] Range (min … max): 69.5 ms … 72.3 ms 41 runs Benchmark #3: hexdump ./target/release/hexyl Time (mean ± σ): 262.4 ms ± 2.8 ms [User: 260.1 ms, System: 1.5 ms] Range (min … max): 259.8 ms … 268.8 ms 11 runs Summary 'xxd ./target/release/hexyl' ran 3.72 ± 0.05 times faster than 'hexdump ./target/release/hexyl' 21.70 ± 0.43 times faster than './target/release/hexyl ./target/release/hexyl' Currently hexyl seems nearly 22x slower than xxd.
  - sharkdp 8y ago
    ... and I have already used hyperfine to benchmark hexyl as well :-) Yes, it's a shame. But I don't think there is too much we can do about it. We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. Surely there are some ways to speed everything up a little bit, but in the end I don't think its a real issue. Nobody is going to look at 1MB dumps in a console hex viewer (that's 60,000 lines of output!) without restricting it to some region. And if somebody really wants to, he can probably spare 1.5 seconds to wait for the output :-)
    - userbinator 8y ago
      We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. A few extra comparisons and output for each byte shouldn't be that much slower; fortunately the function of this program is extremely well-defined, so we can calculate some estimates. Assuming a billion instructions per second, taking ~1.5s to hexdump ~1 million bytes means each byte is consuming ~1500 instructions to process. In reality the time above is probably on a faster CPU, so that number maybe 2-3x more. That is a shockingly high number just to split a byte into two nybbles (expected to be 1-3 instructions), convert the nybbles into ASCII (~3 instructions), and decide on the colour (let's be very generous and say ~100 instructions.) The fact that the binary itself is >1MB is also rather surprising, especially given that the source (not familiar with Rust, but still understandable) seems quite small and straightforward.
- sharkdp 8y ago
  Fixed in v0.3.1 (https://github.com/sharkdp/hexyl/releases/tag/v0.3.1 https://github.com/sharkdp/hexyl/releases/tag/v0.3.1) :-)
udp 8y ago
What difference would that make?

While reading this my hope was it not being written in JavaScript. I'm not disappointed ;)

by hwj 8y ago

While reading this my hope was it not being written in JavaScript. I'm not disappointed ;)

weavie 8y ago

261 lines of pure Rust by the look of it.

dancek 8y ago

I was hoping that it's written in Rust. I wasn't disappointed either.

ConcernedCoder 8y ago

Yeah! -- Because prejudice rocks and JavaScript sucks right?

neysofu 8y ago
Every problem requires appropriate tools. Why would you use a slow and resource-intensive language for a thing as simple as hex viewing?

pantalaimon 8y ago

It's comparably slow though :p xxd `which hexyl` > /dev/null 0.12s user 0.09s system 99% cpu 0.219 total hexdump `which hexyl` > /dev/null 0.19s user 0.05s system 91% cpu 0.256 total hexyl `which hexyl` > /dev/null 1.69s user 0.39s system 95% cpu 2.175 total

sgt 8y ago
It takes a second to compute all that color. Nice tool though - but what I would really like to see is a --color argument added to xxd as well, as I'll probably forget about hexyl down the line and start looking for xxd again (which is conveniently already installed on most *nix systems).
ByronBates 8y ago
The same author also wrote hyperfine, a tool to compare performance of various program runs. hyperfine './target/release/hexyl ./target/release/hexyl' 'xxd ./target/release/hexyl' 'hexdump ./target/release/hexyl' Benchmark #1: ./target/release/hexyl ./target/release/hexyl Time (mean ± σ): 1.529 s ± 0.028 s [User: 1.476 s, System: 0.050 s] Range (min … max): 1.491 s … 1.581 s 10 runs Benchmark #2: xxd ./target/release/hexyl Time (mean ± σ): 70.5 ms ± 0.5 ms [User: 68.0 ms, System: 1.2 ms] Range (min … max): 69.5 ms … 72.3 ms 41 runs Benchmark #3: hexdump ./target/release/hexyl Time (mean ± σ): 262.4 ms ± 2.8 ms [User: 260.1 ms, System: 1.5 ms] Range (min … max): 259.8 ms … 268.8 ms 11 runs Summary 'xxd ./target/release/hexyl' ran 3.72 ± 0.05 times faster than 'hexdump ./target/release/hexyl' 21.70 ± 0.43 times faster than './target/release/hexyl ./target/release/hexyl' Currently hexyl seems nearly 22x slower than xxd.
- sharkdp 8y ago
  ... and I have already used hyperfine to benchmark hexyl as well :-) Yes, it's a shame. But I don't think there is too much we can do about it. We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. Surely there are some ways to speed everything up a little bit, but in the end I don't think its a real issue. Nobody is going to look at 1MB dumps in a console hex viewer (that's 60,000 lines of output!) without restricting it to some region. And if somebody really wants to, he can probably spare 1.5 seconds to wait for the output :-)
  - userbinator 8y ago
    We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. A few extra comparisons and output for each byte shouldn't be that much slower; fortunately the function of this program is extremely well-defined, so we can calculate some estimates. Assuming a billion instructions per second, taking ~1.5s to hexdump ~1 million bytes means each byte is consuming ~1500 instructions to process. In reality the time above is probably on a faster CPU, so that number maybe 2-3x more. That is a shockingly high number just to split a byte into two nybbles (expected to be 1-3 instructions), convert the nybbles into ASCII (~3 instructions), and decide on the colour (let's be very generous and say ~100 instructions.) The fact that the binary itself is >1MB is also rather surprising, especially given that the source (not familiar with Rust, but still understandable) seems quite small and straightforward.
sharkdp 8y ago
Fixed in v0.3.1 (https://github.com/sharkdp/hexyl/releases/tag/v0.3.1 https://github.com/sharkdp/hexyl/releases/tag/v0.3.1) :-)

udp 8y ago

What difference would that make?