Why did you write the python running so slowly?

About a year ago, in 2013 at Waza (place name), Alex Gaynor a good topic: Why do programs written in Python, Ruby, and JavaScript always run slowly? The point, as he emphasized, is that the problem now arises. In other words, although the language is slow now, it does not mean that there is no solution, it does not mean that the future will always be like this.

When asked on the Internet why Python is slower than the C language, the answer is that Python has a dynamic type. However, dynamic types do have a performance impact, but this is not the main reason.

Dynamic types, like Python's primary programming language, make it difficult for the compiler to optimize performance. Dynamic makes each execution possible differently and the compiler is difficult to optimize. However, as Alex mentioned in the conversation, we spent several years studying what the best way to do type checking at runtime is. But nothing has progressed.

In reality, the huge difference between the C language and Python at runtime is due to the difference in data structure and algorithms. Sometimes programmers don't even notice this.

Write different code in Python

Let's use an example that Alex mentions to illustrate the problem. A python programmer might like to use the following example to represent a point on a plane:

1	point ={‘x‘: 0, ‘y‘: 0}

This method is easy to read, easy to encode, and elegant in form.

On the other side, a C-language programmer might use a struct to represent a point on a plane:

1234	struct Point {   intx;   inty;};

Although this approach works the same way as Python does and is elegant, it is a completely different data structure. Here we tell the compiler that we have two fields X and Y. Knowing the types of these two fields, the compiler allocates a contiguous amount of memory to store the two data. In other words, it's like an array. At any time, the compiler knows where the given x and Y are. We can easily access this data as if we were accessing some constant data.

Python uses hashed methods to solve similar problems. Therefore, the compiler cannot simply allocate contiguous memory storage x and Y to handle these problems. These keys may appear in any of these places. If we want to, we may also delete these keys. The compiler must use a hash function to map to any storage unit that you might want to point to. Needless to say, these functions add processing time. Although it may slow down a little, it can slow down your code, especially if it's a lot of things.

If you want to translate Python into C language, it might look like this:

123	std::hash_set<span> point;point[“x”] =xpoint[“y”] =y</span>

Looking at this snippet of code, it seems that the designers of the language themselves deliberately try to make the hash table complex, so though it is correct, no one is using it. For this reason, people who write C may think it is inconceivable, but why is it acceptable in Python?

The reason is that the people who write Python code "dictionaries is lightweight objects" this mentality. Look at the following code, which is closest to the C-language structure in Python:

1234	class point ( object      x, y = none None      def __init__ ( self            self .x, self . y = x, y

This is useful for compilers, like the C language structure. For example, in the second line, we explicitly tell the compiler that we always need at least two data segments when we create an object, and we want the compiler to handle the problem.

Unfortunately, this standard Python is called Cpthon and cannot always be used. On my machine, the following code executes for 186 milliseconds:

123456

def sum_(points):    sum_x, sum_y = 0, 0    for point in points:        sum_x += point[‘x‘]        sum_y += point[‘y‘]    return sum_x, sum_y

It takes 201 milliseconds to replace point[' X ' with Point.x on my machine. In other words, it will be 8% slower.

In Cpthon, point.x is usually treated as dict (point) [' X ']. This means that the class with the dot still looks like it did before using the Dictionary (dictionary) method. In this way, it is easy to see why the Directionary method is seen as "lightweight".

Some python-written code is designed for efficiency, such as pypy, which can be executed very quickly. If you use PyPy instead of Python, the same code fragment execution time is 21.6 and 3.75 milliseconds, respectively. This method is satisfactory compared to CPython in the jit-capable compilation case. In other words, pypy can use data structures correctly.

I want you to see this again. The shortest time is 3.75 milliseconds. This figure shows that we can perform 266,000 operations in a second, from Python, which has dynamic bindings, monkey-patching (the way to extend or modify dynamic language runtime code without changing the source code), and so on. All of this is the use of better data structures in coding and implementation. Next time when you're writing a line of code in Python, think about what data structure you're using, whether it's implicit or not, and consider if there's a better way. That's what you think about when you write programs in C, don't you?

Finally, I would like to believe that this article is a clear example of why Python is a promising language (or a similar language). This shows the standard Python implementation, where the CPython is simply a reference, and it has never been designed to perform faster. As we can see today, the algorithm implementation like PyPy is able to optimize your code to a good length. With the natural development of language, these optimizations are possible. We've only been programming with Python for 23 years, so what would python look like if we had 42 years of development as in C?

1. One might argue that collections.namedtuple () is closer to the C language structure, which is right, but we should not complicate things too much and our focus is on effectiveness.

2. To make it clearer how Python works, refer to the Python documentation.

Original lukauskas.co.uk

Why did you write the python running so slowly?