The original post has examples of how to do it, eg: time ./exwp.exs < words.txt > /dev/null. So to convert your command: elixir wc.exs < words.txt.
jola
0
joaoevangelista
I think I’m doing something wrong, I went to powershell and piped to stdio and timed with :timer.tc/1 and I get 2.5s:
Here is the code
c = fn ->
:ets.new(:words, [{:write_concurrency, true}, :named_table])
IO.stream(:stdio, :line)
|> Stream.flat_map(&String.split(&1, " ")) # using space decrease from approx half than using split/1
|> Enum.each(fn word -> :ets.update_counter(:words, word, {2, 1}, {word, 0}) end)
:ets.match_object(:words, {:"$0", :"$1"})
|> Enum.sort(fn {_, a}, {_, b} -> b < a end)
# print it beautifully
|> Enum.map(fn {word, count} ->
[String.pad_leading(Integer.to_string(count), 8), " ", word, "\n"]
end)
|> IO.write()
end
{micro, :ok} = :timer.tc(c)
IO.puts("#{micro/1000}ms")
IO.puts(":timer.tc/1 #{micro}")
2593.0ms
:timer.tc/1 2593000
If interested these are my versions:
Erlang/OTP 21 [erts-10.3] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]
Elixir 1.8.1 (compiled with Erlang/OTP 20)
Windows 10 Pro 1809
1
jola
Are you sure your output is correct? I ran your code and you have lots of \n in your words, because you split only on " ". Each line ends with a \n. Remove your argument to split, so it says &String.split(&1) or use my solution of compiling a pattern. Also running your code took
37520.331ms
:timer.tc/1 37520331
Maybe you run it faster because your words.txt is too short? Here’s the number of lines in mine
wc -l words.txt
1819045 ../words.txt
You can also read the number of lines in your output. This is how many lines I get from your code (you get almost twice as many lines in your output because of all the new line characters, I believe you should get 557K if your original file has 1.8M lines)
elixir wc.exs < ../words.txt | wc -l
935401
If you look at the original article the fastest C version took 3.7s, so there’s probably something wrong here 
0
joaoevangelista
Oooh It makes sense, I counted the words and it’s way below yours, I thought I got it right from the file but maybe it was still downloading when I saved.
Also I noticed that without " " on split it takes way longer! Thank you for the findings!
0
jeramyRR
I think running an exs is going to be slower than running a compiled release in any case, so this benchmark won’t accurately reflect a real world case of a deployed app. Please correct me if I’m wrong everyone.
2
jola
.exs files are also compiled, it just automatically happens before it runs. Obviously that means you keep paying that cost, but for a tiny script like this, you’re not gonna notice it. Also measurements are of execution time, not startup.
Building a release does not apply any performance optimizations, it just compiles the code like you would otherwise with MIX_ENV=prod mix compile, AFAIK. There are no mentions in the Distillery docs of releases being faster. It’s not what releases are for.
0
josevalim
Creator of Elixir
To clarify, it depends on the .exs file, but for other reasons besides compilation.
Running elixir path/to/exs won’t have any protocol consolidated. Running inside a Mix project with mix run path/to/exs (and also in a release) may be more performant depending on the idioms used. I don’t think it would in this case though.
2
jola
Yeah, I can confirm that running mix run vs elixir doesn’t appear to make a difference, at least enough that it’s measurable in this simplistic benchmark.
Here’s three runs each of elixir and mix run
➜ app mix run lib/nodep.exs < ../words.txt >/dev/null
22379157
➜ app mix run lib/nodep.exs < ../words.txt >/dev/null
24923662
➜ app mix run lib/nodep.exs < ../words.txt >/dev/null
22455488
➜ app elixir lib/nodep.exs < ../words.txt >/dev/null
22172380
➜ app elixir lib/nodep.exs < ../words.txt >/dev/null
22035877
➜ app elixir lib/nodep.exs < ../words.txt >/dev/null
22763843
The single outlier at 24s can pretty safely be ignored.
But again, none of this is a proper benchmark. All we’ve shown is that Elixir can be written to perform decently in a text processing script. The original article 2019 ruby 2.6 version took 37s, meaning we’re quite a lot faster than ruby at this point.
0
ellispritchard
For the serial code, it knocks about 6 seconds off for me (1m13 vs 1m19 - 2GHz MacBook) if I use a un-named ETS table, i.e.
table = :ets.new(:words, [])
and then use the reference directly instead of the name:
|> Enum.each(fn word -> :ets.update_counter(table, word, {2, 1}, {word, 0}) end)
etc.
This makes sense since now ETS doesn’t have to be concerned about concurrency at all, and there’s no lookup for the table by name.
Of course, now you can’t take advantage of concurrency 
0
evadne
Hi, a friend of mine sent this over, so I gave it a try: .gitignore · GitHub
FWIW
$ curl http://teralink.net/\~serpent/words.txt > words.txt
$ md5 words.txt
MD5 (words.txt) = 640ef9e082ef75ef07f0e9869e9d8ae2
$du -h words.txt
217M words.txt
Execution
$ elixir ./count.ex ./words.txt --sort > out-sorted.txt
Started
Using 4 Workers
Processing: 4.748574s
Load Results: 0.820397s
Order Results: 1.99405s
Print Results: 3.136065s
Total Runtime: 10.710908s
$ elixir ./count.ex ./words.txt > out.txt
Started
Using 4 Workers
Processing: 4.944752s
Load Results: 0.836416s
Print Results: 2.556994s
Total Runtime: 8.343633s
$ wc -l out*
557745 out-sorted.txt
557745 out.txt
1115490 total
$ head -n 5 out-sorted.txt
1033175 0
103404 00
353 000
752 0000
19 00000
Please let me know your thoughts. Thanks again!
8