4 ms·

You don't need to go that far for GC's bad rep considering that excruciatingly slow Python can be found TODAY!

by pyeri 3y ago

DarkNova6 3y ago
But you must understand, Python is safe and C is difficult. Therefore, to be fast we need Python (fast development that is because nobody _really_ cares about performance (or maintainability)). If only more than two languages would exist!
- h4ch1 3y ago
  > fast development that is because nobody _really_ cares about performance (or maintainability) This is either 1. missing a /s 2. delusion 3. bait
  - tmtvl 3y ago
    I believe it's 1, considering the statement 'If only more than two languages would exist!'. Granted, sarcasm doesn't transmit well in written text.
amelius 3y ago
Python wasn't designed for speed.
torginus 3y ago
Afaik (C)Python uses reference counting, it's slowness comes from the interpreter itself.
- _flux 3y ago
  It uses also tracing GC to handle RC loops. I guess doing it this way allows to have mostly deterministic collection (that is then just an implementation feature, not language semantics) while needing the actual tracing GC to not be that efficient, as it presumably needs to be executed less rarely.
- kaba0 3y ago
  Ref counting is a GC-algorithm, and the slowest at that (especially with multi-core sync, but that’s not the case with python), as a tradeoff for less memory consumption.
adev_ 3y ago
> You don't need to go that far for GC's bad rep considering that excruciatingly slow Python can be found TODAY! To be fair, the GC is probably the last reason of Python speed problems. Many languages also designed with GC performs significantly better than python in term of raw performance [^1]. The extremely dynamic nature of python associated with its reference semantics are probably significantly more to blame here. [^1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

You don't need to go that far for GC's bad rep considering that excruciatingly slow Python can be found TODAY!

by pyeri 3y ago

You don't need to go that far for GC's bad rep considering that excruciatingly slow Python can be found TODAY!

But you must understand, Python is safe and C is difficult. Therefore, to be fast we need Python (fast development that is because nobody _really_ cares about performance (or maintainability)). If only more than two languages would exist!

h4ch1 3y ago
> fast development that is because nobody _really_ cares about performance (or maintainability) This is either 1. missing a /s 2. delusion 3. bait
- tmtvl 3y ago
  I believe it's 1, considering the statement 'If only more than two languages would exist!'. Granted, sarcasm doesn't transmit well in written text.

amelius 3y ago

Python wasn't designed for speed.

torginus 3y ago

Afaik (C)Python uses reference counting, it's slowness comes from the interpreter itself.

_flux 3y ago
It uses also tracing GC to handle RC loops. I guess doing it this way allows to have mostly deterministic collection (that is then just an implementation feature, not language semantics) while needing the actual tracing GC to not be that efficient, as it presumably needs to be executed less rarely.
kaba0 3y ago
Ref counting is a GC-algorithm, and the slowest at that (especially with multi-core sync, but that’s not the case with python), as a tradeoff for less memory consumption.

adev_ 3y ago

> You don't need to go that far for GC's bad rep considering that excruciatingly slow Python can be found TODAY! To be fair, the GC is probably the last reason of Python speed problems. Many languages also designed with GC performs significantly better than python in term of raw performance [^1]. The extremely dynamic nature of python associated with its reference semantics are probably significantly more to blame here. [^1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...