Timeline for Working through the single responsibility principle (SRP) in Python when calls are expensive
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 16, 2019 at 14:41 | comment | added | Steven Jackson | @jpmc26 I have added a new footnote to my answer to address some of the (very good) concerns you raise about using PyPy in production. You helped me realize I had some implicit assumptions based on my professional history which may not be valid for the OP, so they should be explicitly mentioned. | |
| Apr 16, 2019 at 14:34 | history | edited | Steven Jackson | CC BY-SA 4.0 |
Added More details about PyPy
|
| Apr 16, 2019 at 14:12 | comment | added | Steven Jackson | @jpmc26 I agree fully. I have been working in companies that already used microservices for unrelated reasons, and in that situation I found selective usage of PyPy to have very few drawbacks with strong benefits. I would not use PyPy as a major reason to choose to use microservices in the first place. Since we already had microservices in multiple different languages, adding a new interpreter to that mix did not complicate things appreciably. | |
| Apr 15, 2019 at 23:40 | comment | added | jpmc26 | @StevenJackson Microservices have their own set of long term headaches. Deciding to use them categorically just to enable the use of PyPy on some of them is not a good design decision. | |
| Apr 15, 2019 at 14:11 | comment | added | Steven Jackson | @jpmc26 if you have a monolith, or even large services, you can get into trouble with PyPy not playing nice with certain libraries that you find you need only after you've written most of your code with the idea PyPy was going to make it fast, and that can be a serious problem. If you have small microservices, however, you can pick PyPy or CPython on a per-microservice basis without causing yourself any longterm headaches. Just make sure your tests run it under both interpreters and pass in both cases in case you do need to make a change later. | |
| Apr 15, 2019 at 14:06 | comment | added | Steven Jackson | @ewan, (cont.) So if you meaning is "don't you pay the same overhead for calling A even if the JIT optimizes it?" then yes, you do. But overall function call overhead in your program is still substantially lower, which is more likely what you're worried about in any case. | |
| Apr 15, 2019 at 14:01 | comment | added | Steven Jackson | @ewan, functions can be inlined as part of the Just in Time Compilation process. If you directly call A, A calls 5 different functions, each of which call 3 other functions, you pay function call overhead (1 + 5 + 5 *3) = 21 times. If that all gets inlined by the JIT as part of optimizing function A, then you will only pay function cal overhead for A, which is 21 times less (the rest of the function calls disappear because the functions were inlined). | |
| Apr 15, 2019 at 13:57 | comment | added | Steven Jackson | @lucasgcb Yes, OOP would still be a sensible approach in my view. | |
| Apr 15, 2019 at 13:56 | comment | added | Steven Jackson | @jpmc26 I've used PyPy in production, and recommend considering doing so to other experienced developers. It is great for microservices using falconframework.org for lightweight rest APIs (as one example). Behavior differing because developers rely on implementation details which are NOT a guarantee of the language is not a reason to not use PyPy. It's a reason to rewrite your code. The same code may break anyway if CPython make changes to its implementation (which it is free to do as long as it still conforms to the language spec). | |
| Apr 14, 2019 at 11:06 | comment | added | Ewan | I think you hit the nail on the head though. There's no reason you couldn't have a better interpreter, or a compiler. It's not intrinsic to python as a language. You are just stuck with practical realities | |
| Apr 14, 2019 at 7:29 | comment | added | jpmc26 | CPython is the only interpreter that is generally taken seriously. PyPy is interesting, but it certainly isn't seeing any kind of widespread adoption. Furthermore, it's behavior differs from CPython, and it doesn't work with some important packages, e.g. scipy. Few sane developers would recommend PyPy for production. As such, the distinction between the language and the implementation is inconsequential in practice. | |
| Apr 14, 2019 at 5:42 | comment | added | Ewan | with case 1 (2nd para) do you not get the same over head calling the functions, even if the functions themselves are complied? | |
| Apr 13, 2019 at 21:59 | comment | added | lucasgcb | Yeah! I've been considering focus on C extensions for this case instead of abandoning the principle and writing wild code, the other answers gave me the impression it would be slow regardless unless I swapped from the reference interpreter - To clear it up, OOP would still be a sensible approach in your view? | |
| Apr 13, 2019 at 20:55 | review | First posts | |||
| Apr 15, 2019 at 13:37 | |||||
| Apr 13, 2019 at 20:51 | history | answered | Steven Jackson | CC BY-SA 4.0 |