Great reminder. I have also gotten a lot of speed up in parsing data strings by avoiding the use of streams. A bit of a downside is that string_view is C++17. Three years down the road do you think C++17 is already widely adopted?
Jounisays:
Wide adoption can mean many things. In bioinformatics, I’ve found it useful to consider the default compilers installed in the field. If server lifespan is 5 years, it can take 5-6 years for a new C++ standard to be widely supported. C++14 reached that point recently, while C++17 is still some years away.
My experience is that C++17 is widely available at this point, but rolling your own string_view-like class is not hard.
Johnsays:
This article states something obvious and basically lacks a point. just seems a cheap sneer at ‘high level’ languages. No one writes performance sensitive code in python or JavaScript.
I am sure it was obvious to you, but what makes you believe that it is obvious to everyone?
and basically lacks a point.
I disagree. I think that this blog post makes a clear point.
just seems a cheap sneer at ‘high level’ languages.
It is not. I make my point using C++. If I wanted to make Python look bad, I would have used another approach.
No one writes performance sensitive code in python or JavaScript.
I disagree. Python and R are the dominant languages in data science. It is entirely possible to have high-performance data processing in Python and R. Of course, the heavy lifting won’t be done in pure Python or in pure R.
Eugene Epshteynsays:
No one writes performance sensitive code in python or JavaScript.
You can recycle heap-allocated objects to good effect. Many programs have a cyclic workload, so reusing the allocations from the first cycle can save a lot. And … never been fond of C++ strings. An approach I first adopted in the mid-1990s: https://bannister.us/weblog/2005/building-a-better-string-class
Davidsays:
People just need to understand that memory allocations are costly, so if you want fast code, you want to minimize the number of “mallocs”.
Each std::string object is creating such an alloc, that’s why if you create thousands, it gets very slow. std::string_view doesn’t allocate memory, so that’s why it’s faster to use it if you can.
Same thing when you want to grow an std::string, like: += “x” multiple times. It will cause a few memory reallocations, so that’s why if you know the size that you’ll end up with, it’s much faster to reserve the memory beforehand, and then do the concatenations, because you’re allocating the memory only once instead of many times.
Great reminder. I have also gotten a lot of speed up in parsing data strings by avoiding the use of streams. A bit of a downside is that string_view is C++17. Three years down the road do you think C++17 is already widely adopted?
Wide adoption can mean many things. In bioinformatics, I’ve found it useful to consider the default compilers installed in the field. If server lifespan is 5 years, it can take 5-6 years for a new C++ standard to be widely supported. C++14 reached that point recently, while C++17 is still some years away.
My experience is that C++17 is widely available at this point, but rolling your own string_view-like class is not hard.
This article states something obvious and basically lacks a point. just seems a cheap sneer at ‘high level’ languages. No one writes performance sensitive code in python or JavaScript.
I am sure it was obvious to you, but what makes you believe that it is obvious to everyone?
I disagree. I think that this blog post makes a clear point.
It is not. I make my point using C++. If I wanted to make Python look bad, I would have used another approach.
I disagree. Python and R are the dominant languages in data science. It is entirely possible to have high-performance data processing in Python and R. Of course, the heavy lifting won’t be done in pure Python or in pure R.
Many people seem to. Intel even has a distribution of Python optimized for Intel hardware: https://software.intel.com/content/www/us/en/develop/tools/distribution-for-python.html
You can recycle heap-allocated objects to good effect. Many programs have a cyclic workload, so reusing the allocations from the first cycle can save a lot. And … never been fond of C++ strings. An approach I first adopted in the mid-1990s:
https://bannister.us/weblog/2005/building-a-better-string-class
People just need to understand that memory allocations are costly, so if you want fast code, you want to minimize the number of “mallocs”.
Each std::string object is creating such an alloc, that’s why if you create thousands, it gets very slow. std::string_view doesn’t allocate memory, so that’s why it’s faster to use it if you can.
Same thing when you want to grow an std::string, like: += “x” multiple times. It will cause a few memory reallocations, so that’s why if you know the size that you’ll end up with, it’s much faster to reserve the memory beforehand, and then do the concatenations, because you’re allocating the memory only once instead of many times.