Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

juliacomputing.com

Post reply on HN
Print view View original

111–120 of 236 posts

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#111

Post by datanecdote »

StefanKarpinski wrote: post #99
dmw_ng wrote: post #51

There is a ton of conflation in this post, yesterdays post, and the comments. * Comparing parallel implementations (Julia) to single thread (Python csv module). This is still quite relevant because in places like Python, it is impossible to parallelize the csv module without essentially updating its native implementation. That's not true in other places, where some simple wrapper code may be all required to get that…

You may be missing the point of the comparison, which is this: to compare the performance of the de facto standard CSV parsers of each system when used the way that a typical user would use them, i.e. to parse a CSV file into a data frame. Regarding your specific points: 1. Yes, it's possible to rig up some way of parsing in parallel in Python, like splitting the CSV file into multiple files and then parsing them in…

> 2. I don't entirely follow this point. Perhaps using PyArrow's parser would be faster than what is timed here, but is that what the typical Python data science user would do?

I am a Python data science user. If data gets big enough such that loading time is a bottleneck, I use parquet files instead of CSV, and PyArrow to load them into pandas. It’s a one line change. The creator of Pandas is now leading the Arrow project. It’s very seamless. Don’t know if I’m typical but that’s me.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#112

Post by jpeloquin »

throwaway894345 wrote: post #68
bonoboTP wrote: post #14

Maybe I'm a cranky old man, but I think there's immense value in the fact that Python's (scientific and non-scientific) ecosystem has matured and has become standard over the last 1-2 decades. Starting again from the ground up in a shiny new language (even if the language is perhaps slightly better) is a waste of so much effort. Transitioning from Python 2 to 3 was already a nightmare. I know there's some interoperab…

> Starting again from the ground up in a shiny new language (even if the language is perhaps slightly better) is a waste of so much effort. Transitioning from Python 2 to 3 was already a nightmare. This is a sunk cost argument. Python’s stack got us a long way, but it still falls short in a lot of ways. First of all, it is eager so you can’t build up an entire query, have the system optimize it, and then execute it f…

> Fifthly, the APIs were horribly designed (especially matplotlib, good grief)

I've seen comments like this fairly often, but am not really sure what about matplotlib's API makes it so bad. Hoping to learn why.

The only equal-basis competitor to matplotlib that I'm familiar with is Matlab, which is definitely worse. Declarative plotting libraries like ggplot2 have a nicer API, but the grammar of graphics approach is an entirely different paradigm, which gets as thorny as anything else if you have to do something unexpected. For the kind of medium-level plotting where you're given prepared plot elements, but have to explicitly specify where to draw them in data or figure coords, what would be an example of a "good" API (better than matplotlib)?

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#113

Post by nnm »

> The tools used for benchmarking were BenchmarkTools.jl for Julia, microbenchmark for R, and timeit for Python.

Is this a meaningful comparison? These benchmarks repeatedly call the function (with same input file) many times and then take the average of the time spent. However, in real world, we only read a specific file ONCE -- if we call the csv reader several times, it is almost always for different files.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#114

Post by StefanKarpinski »

mlthoughts2018 wrote: post #110
StefanKarpinski wrote: post #105

Earlier quoted context omitted.

The fact that the standard CSV reader is not good enough to actually use except in toy applications is itself an issue, frankly.

I disagree completely. It’s perfectly good enough for non-specialized use cases, which is exactly right for a stdlib offering. For anything else, factor it out as separate third party options (even if maintained by PSF itself) so users only install what they need for their special application. One person may install something that’s blazingly fast. Someone else may install something because it can convert the data to…

Interestingly, CSV.jl can do all of those. This seems like a classic case of lack of composability in Python: you need a different CSV parser for each and every application even though the core logic of parsing the CSV format is the same. This is because anything fast has to be implemented in very concrete, specialized C code. In Julia, you can write something generic and let the compiler specialize it for you, so you get many different ways of applying the same thing for free.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#115

Post by drej »

StefanKarpinski wrote: post #105
mlthoughts2018 wrote: post #102

Earlier quoted context omitted.

A typical user will rarely ever use the built in CSV library in Python, and would choose among the many third party options for much greater performance, ease of use, parity with rectangular data structure tools like pandas, and so forth. Comparing anything against the built-in CSV reader in Python is pretty much an exercise in nothing. In 20 years of programming Python professionally, I have used the built in CSV pa…

The fact that the standard CSV reader is not good enough to actually use except in toy applications is itself an issue, frankly.

Except that it can. I hardly ever use something other than stdlib’s csv. It’s a perfectly good csv parser for production use.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#116

Post by qaq »

langitbiru wrote: post #109
dmos62 wrote: post #5

Earlier quoted context omitted.

> Julia will be the killer lang for building web apps That would be fun, but Julia's community aren't web devs. Julia spawned around very specific needs of scientific computing, which is characterised by a short-running daemon or a script-type interpreter. A web server is a long-running process. Not knowledgeable enough about Julia to tell how it lends itself to server uses, but heard hearsay that it's problematic.

Seconded this. If you looked at the Julia website ( https://julialang.org ), in the Ecosystem section, they listed these things: "Visualization, General Purpose, Data Science, Machine Learning, Scientific Domains, Parallel Computing." They already positioned themselves in scientific computing battleground. Web development (or desktop programming) is not their focus (for better or worse).

Julia is very capable general purpose lang and web libs are maturing pretty fast. It does not have to be the focus of core team for it to happen.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#117

Post by drej »

StefanKarpinski wrote: post #114
mlthoughts2018 wrote: post #110

Earlier quoted context omitted.

I disagree completely. It’s perfectly good enough for non-specialized use cases, which is exactly right for a stdlib offering. For anything else, factor it out as separate third party options (even if maintained by PSF itself) so users only install what they need for their special application. One person may install something that’s blazingly fast. Someone else may install something because it can convert the data to…

Interestingly, CSV.jl can do all of those. This seems like a classic case of lack of composability in Python: you need a different CSV parser for each and every application even though the core logic of parsing the CSV format is the same. This is because anything fast has to be implemented in very concrete, specialized C code. In Julia, you can write something generic and let the compiler specialize it for you, so yo…

Lack of composability? What? Of course you can use one parser for everything, what’s stopping you from doing that. Separating IO from business logic and composing the two is a pretty standard practice. Not sure I follow the argument here.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#118

Post by TkTech »

varbhat wrote: post #16

Well, Julia is compiled .Python and R are both interpreted. I think that simdjson is fastest json parser out there( Parsing gigabytes of JSON per second ). https://github.com/simdjson/simdjson So,if I use Python binding for simdjson , then parsing of json in python must be very much faster than the fastest one mentioned in the above post. So,at the end,it depends on implementation not only on language.

The overhead in all Python JSON parsers isn't parsing the JSON, it's building the Python objects that represent each element. If Julia has lower overhead objects, or JITs with basic optimizations, it would be trivial to be faster than pysimdjson.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#119

Post by cbkeller »

drej wrote: post #115
StefanKarpinski wrote: post #105

Earlier quoted context omitted.

The fact that the standard CSV reader is not good enough to actually use except in toy applications is itself an issue, frankly.

Except that it can. I hardly ever use something other than stdlib’s csv. It’s a perfectly good csv parser for production use.

Doesn't that validate the applicability of the benchmark then? GP said:

> A typical user will rarely ever use the built in CSV library in Python

as a criticism of the benchmark, but if a typical user does use stdlib’s csv after all, then it seems like your disagreement is perhaps with GP and not with Stefan.

Re: CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

#120

Post by mlthoughts2018 »

StefanKarpinski wrote: post #114
mlthoughts2018 wrote: post #110

Earlier quoted context omitted.

I disagree completely. It’s perfectly good enough for non-specialized use cases, which is exactly right for a stdlib offering. For anything else, factor it out as separate third party options (even if maintained by PSF itself) so users only install what they need for their special application. One person may install something that’s blazingly fast. Someone else may install something because it can convert the data to…

Interestingly, CSV.jl can do all of those. This seems like a classic case of lack of composability in Python: you need a different CSV parser for each and every application even though the core logic of parsing the CSV format is the same. This is because anything fast has to be implemented in very concrete, specialized C code. In Julia, you can write something generic and let the compiler specialize it for you, so yo…

> “ Interestingly, CSV.jl can do all of those.“

That sounds like a poorly designed library to me. Instead of doing one thing well, it forces users to consume something meant as a jack of all trades, which may not meet their use case.

I wish such a thing wasn’t forced in a standard package - rather split into different ones. Then I can easily compose them according to my needs, instead of having the stdlib force feed me some set of tradeoffs I might not want.

I’m sure these extra third party libraries exist or will exist in Julia just as they do in Python and users will have lots of good options - but what a shame for people to take a needlessly myopic view that core libraries need to be obsessed either with performance or with breadth of use case coverage coupled into one library, which seems to purely be for macho bragging rights or something?

Post reply on HN