What do these layers of abstraction do?
hst337
josevalim
Creator of Elixir
raw has no effect on read. It is only for file handles. In this case, still goes to a server that serializes both reads and writes. I will try to start a discussion on why that’s the case. It feels unnatural to try to address a race condition that is natural to the file system itself and will happen with other programs running in the same machine anyway.
2
BradS2S
It looks like the overhead is spinning up a new process:
raw
Allows faster access to a file, as no Erlang process is needed to handle the file. However, a file opened in this way has the following limitations:
- The functions in the io module cannot be used, as they can only talk to an Erlang process. Instead, use functions read/2,read_line/1, and write/2.
- Especially if read_line/1 is to be used on a raw file, it is recommended to combine this option with option {read_ahead, Size} as line-oriented I/O is inefficient without buffering.
- Only the Erlang process that opened the file can use it.
- A remote Erlang file server cannot be used. The computer on which the Erlang node is running must have access to the file system (directly or through NFS).
When the mode isn’t raw, the iodevice is a pid.
3
fireproofsocks
Thank you all for the continued input. This is interesting! I formalized my repo to use Benchee so I could continue trying out some variants. Here are the results (so far):
Name ips average deviation median 99th %
python 2.27 0.44 s ±22.35% 0.45 s 0.64 s
:prim_file async 1.38 0.72 s ±22.75% 0.63 s 1.04 s
Concurrent 0.63 1.59 s ±8.90% 1.59 s 1.78 s
Split file 0.40 2.51 s ±22.56% 2.35 s 3.30 s
Task.async_stream 0.32 3.16 s ±21.99% 3.19 s 3.95 s
:prim_file 0.31 3.26 s ±41.38% 2.82 s 5.19 s
File 0.31 3.27 s ±24.74% 3.48 s 4.00 s
Jsonrs 0.28 3.54 s ±20.90% 3.56 s 4.27 s
Comparison:
python 2.27
:prim_file async 1.38 - 1.64x slower +0.28 s
Concurrent 0.63 - 3.59x slower +1.14 s
Split file 0.40 - 5.68x slower +2.07 s
Task.async_stream 0.32 - 7.16x slower +2.72 s
:prim_file 0.31 - 7.37x slower +2.81 s
File 0.31 - 7.41x slower +2.83 s
Jsonrs 0.28 - 8.02x slower +3.10 s
In short, Python is still the fastest. The fastest Elixir solution (so far) is the one that uses Task.async_stream and the :prim_file:
index_file
|> File.stream!()
|> Task.async_stream(fn line ->
path = String.trim(line)
{:ok, contents} = :prim_file.read_file(path)
{:ok, %{"paths" => txt_paths}} = Jason.decode(contents)
Enum.each(txt_paths, fn p ->
:prim_file.read_file_info(p)
end)
end)
|> Stream.run()
I tried variants that used EITHER Task.async_stream OR :prim_file, but they didn’t perform as well. Loading the file into memory instead of streaming it also didn’t perform as well. I haven’t been able to get jiffy working, so I gave jsonrs a try, but unfortunately, it performed the worst of these (!!).
What is challenging here is that the solutions have very different performance characteristics. In other words, it’s easy to fall into a hole here, so I’m hoping to identify patterns to avoid. I should probably try coming up with more simplified use-cases, because this one touches on a lot of things: streaming, checking the file system, and JSON decoding.
2
dogweather
I’m interested in Elixir solutions that are not only faster, but also as clean and naive as the Python solution (from above). It doesn’t use any special Python libraries. It doesn’t obviously drop into C code (like the best Elixir version uses Erlang functions and types. ?)
This is very clean code (literally, in Bob Martin’s Clean Coding style.)
from os.path import exists
import json
from time import time
index_file = "tmp/files/index.txt"
existing = []
def vet_files():
with open(index_file, 'r') as myfile:
for line in myfile:
open_json_file(line.rstrip())
# dict_obj = json.loads(person_data)
def open_json_file(json_file):
with open(json_file, 'r') as myfile:
for line in myfile:
data = json.loads(line)
files_exist(data['paths'])
def files_exist(paths):
for p in paths:
existing.append(exists(p))
if __name__ == "__main__":
start_time = int(time() * 1000)
vet_files()
end_time = int(time() * 1000)
print(f'Duration: {end_time - start_time} ms')
print(all(existing))
0
BradS2S
I’d be curious how it would do against raw file
index_file
|> :file.open([:raw, :read_ahead])
|> :file.read(1_000_000)
|> ...
0
D4no0
Is that so? Only because you are using a python function to call the library function is doesn’t mean there isn’t a native C implementation under the hood.
What about the abomination the python is at this moment in time? Nobody can’t understand at this point if the language is interpreted or compiled anymore because of how many optimizations are in place to make it fast.
like the best Elixir version uses Erlang functions and types
If you are just getting in elixir you might be thinking that using an erlang library is strange and it is the same as calling C code, however this is definitely not true as elixir gets compiled to erlang, so no overhead is involved here.
Moreover if you have access to 2 separate languages and ecosystems without any setup and overhead why not use whats best from both worlds?
This is very clean code (literally, in Bob Martin’s Clean Coding style.)
Is that so? What about concurrency? The elixir solution above is either using tasks or streams and you are showing a solution that can run only in a blocking manner.
1
fireproofsocks
Just for the record, that was my Python code and I made no attempts to optimize – I just poked at it for a few minutes until it worked. 
3
fireproofsocks
Reading chunks of data (instead of lines) is awkward in this case because each line contains a value. When processing chunks, you have to manually split on newlines and reassemble any values that got split. (At least, I need more coffee before I can come up with a solution to that). Also :file.read/2 returns charlists, and I’m not sure what kind of overhead it would be introducing to convert those back into strings.
1