3 ms·

> it rarely is the bottleneck. If you're using python, it can be the bottle neck quite easily. I don't endorse change language as an optimisation; that's just

> it rarely is the bottleneck. If you're using python, it can be the bottle neck quite easily. I don't endorse change language as an optimisation; that's just ridiculous. ...but you might look at splitting your application up into parts, and doing some service in a more suitable language; or, up front realizing that you have a heavy data processing workload you need to do in parallel, and python isn't a good choice for it. Maybe you're right; you can look at optimisations that patch over the problem with queries and so forth as a first pass; but in some cases your choice of language (specifically node and python in my experience) are actually fundamentally the performance problem (but to be fair, not always). ...but basically, if you don't address the root cause of your perf issues (whatever they are), you're going to be patching and firefighting forever.

luord 9y ago
> If you're using python, it can be the bottle neck > data processing workload you need to do in parallel It's funny how often those two go together, you're of course correct (for now). I never wrote that the language couldn't be the bottleneck, though. If you are doing something that requires heavy parallelization then, by all means, don't use python or replace it if you're already using it... But that kind of workloads isn't actually a common (i.e. 50% or more of all applications) scenario. > ...but basically, if you don't address the root cause of your perf issues (whatever they are), you're going to be patching and firefighting forever. Yes, that's what I'm saying: Find the bottleneck and solve that. I was only addressing the, in my opinion, undue focusing on languages of the comment I replied to. > quite easily Only if one is working with poor developers. And this is true for all languages.
- shadowmint 9y ago
  > Only if one is working with poor developers It's not about the developers, it's about the workload. Objectively, you can't write high performance multi-threaded python. No one can; it's not possible; it's just slow. If you're rewriting your code in C++ so its not slow and pretending its python, you should just rewrite your code in C++. That's not writing fast python, it's writing C++. /shrug So python can easily be a bottle neck, regardless of how good your developers are, if you've picked it for a poor purpose: That's my point: Don't pick the wrong language for your task in the first place. ...and specifically python is the wrong choice for certain types of heavy lifting.
  - luord 9y ago
    > it's about the workload. ... Why did you repeat yourself? I already told you I agreed with you on that. Is it something specific you want me to tell you? It's going to be easier if you tell me what you want to read, otherwise we'll keep going in circles. > Quite easily [...] poor purpose That's an immediate contradiction. Yes, if one picks the wrong tool, that tool often becomes the bottleneck; but for every other scenario in which the tool is alright, it takes poor developers for the tool to become a bottleneck. In my first comment I wrote that the language isn't the bottleneck, except for specific circumstances... And you took one of those specific circumstances and keep running with it. It's not a counterargument to my original point, if that's what you're trying to do.

luord 9y ago

> If you're using python, it can be the bottle neck > data processing workload you need to do in parallel It's funny how often those two go together, you're of course correct (for now). I never wrote that the language couldn't be the bottleneck, though. If you are doing something that requires heavy parallelization then, by all means, don't use python or replace it if you're already using it... But that kind of workloads isn't actually a common (i.e. 50% or more of all applications) scenario. > ...but basically, if you don't address the root cause of your perf issues (whatever they are), you're going to be patching and firefighting forever. Yes, that's what I'm saying: Find the bottleneck and solve that. I was only addressing the, in my opinion, undue focusing on languages of the comment I replied to. > quite easily Only if one is working with poor developers. And this is true for all languages.

shadowmint 9y ago
> Only if one is working with poor developers It's not about the developers, it's about the workload. Objectively, you can't write high performance multi-threaded python. No one can; it's not possible; it's just slow. If you're rewriting your code in C++ so its not slow and pretending its python, you should just rewrite your code in C++. That's not writing fast python, it's writing C++. /shrug So python can easily be a bottle neck, regardless of how good your developers are, if you've picked it for a poor purpose: That's my point: Don't pick the wrong language for your task in the first place. ...and specifically python is the wrong choice for certain types of heavy lifting.
- luord 9y ago
  > it's about the workload. ... Why did you repeat yourself? I already told you I agreed with you on that. Is it something specific you want me to tell you? It's going to be easier if you tell me what you want to read, otherwise we'll keep going in circles. > Quite easily [...] poor purpose That's an immediate contradiction. Yes, if one picks the wrong tool, that tool often becomes the bottleneck; but for every other scenario in which the tool is alright, it takes poor developers for the tool to become a bottleneck. In my first comment I wrote that the language isn't the bottleneck, except for specific circumstances... And you took one of those specific circumstances and keep running with it. It's not a counterargument to my original point, if that's what you're trying to do.