3 ms·

You'd never release a new version of anything that was slower? What if the new thing had 100x more (useful) features, should it still be as fast? Performance

by comice 15y ago

You'd never release a new version of anything that was slower? What if the new thing had 100x more (useful) features, should it still be as fast? Performance is a trade-off and sometimes it's worth compromising.

fauigerzigerk 15y ago
If I'm writing a framework on which others depend in ways I cannot entirely foresee, then the old features _must_ perform as well or better than before. No compromises.
- lhnz 15y ago
  Out of interest, what language is your framework for? I'm seriously thinking of stopping using PHP because of the weight of the frameworks -- at least on Python there are microframeworks in which I am not left with a massive bottlenecks on the simplest Hello World page. Sure, you can scale but it's becoming ridiculous that I am forced to be so frugal with processor intensive tasks in the rest of the web application just because of the framework.
  - fauigerzigerk 15y ago
    My own framework and ORM writing days are long past and the software I write nowadays has very different constraints (data/text mining). I totally share your sentiment about having to be frugal because of wasteful frameworks. My approach is to prefer libraries over frameworks. I start out using the most bare-bones configuration possible (no frameworks, no ORM, no CMS, etc) and then I selectively add well maintained libraries created by people whose attitude I understand. I think code reuse is generally overrated, particularly when it comes to the rather trivial things that web frameworks do. This is probably not very helpful to you. I apologize.
  - coolgeek 15y ago
    http://codeigniter.com/ http://codeigniter.com/
- johnb 15y ago
  That position of "no compromises" is probably why you're not writing a framework on which others depend. Complex software always involves compromises, especially general purpose frameworks used by a large population. Even if you're saying that only in performance there can be no compromises (but generally people who say things like no compromises don't bound those statements) it will cause large compromises in other areas, such a future feature development or long term maintainability and readability.
  - fauigerzigerk 15y ago
    Perhaps you should leave comments about my personality to those who actually know me. But if you insist on talking about character traits, let me say this to you: People who don't know where to compromise and where not to comproise generally make bad software.
    - asomiv 15y ago
      Compromises from whose point of view? One man's good compromise is another man's bad compromise.
      - fauigerzigerk 15y ago
        All I can do is state my own point of view as clearly as I can. And my point of view is already a compromise. I didn't say make it as fast as possible even if you have to rewrite it in assembly. I didn't even say, don't write it in Ruby. All I said is don't make it significantly slower than it was before. That doesn't seem like such a big ask.
    - johnb 15y ago
      That's a fair call - I don't know you and I am speaking about character traits. I don't feel your original comment reflected a position on knowing where to (or not) compromise, you made a strong assertion to take one option off the table in all situations. In my experience, developers who are make blanket rules up front about what can and can't be changed in the future development of a system don't end up making much of value. That's just my perspective, and I apologise if I've misread your character.
- DisposaBoy 15y ago
  If that's taken as written then it's plain and simply impossible - no debate. I can understand that a significant slowdown might be a problem but otherwise it's just much ado about nothing really. What matters most is perceived performance degradation. I'd go as far as to presume? that most if not all people cannot actually the difference between an operation that takes (e.g) 100ms and one that takes 500ms yet when you look at the percentage difference it's clearly an unacceptable performance drop.

by comice 15y ago

fauigerzigerk 15y ago

If I'm writing a framework on which others depend in ways I cannot entirely foresee, then the old features _must_ perform as well or better than before. No compromises.

lhnz 15y ago
Out of interest, what language is your framework for? I'm seriously thinking of stopping using PHP because of the weight of the frameworks -- at least on Python there are microframeworks in which I am not left with a massive bottlenecks on the simplest Hello World page. Sure, you can scale but it's becoming ridiculous that I am forced to be so frugal with processor intensive tasks in the rest of the web application just because of the framework.
- fauigerzigerk 15y ago
  My own framework and ORM writing days are long past and the software I write nowadays has very different constraints (data/text mining). I totally share your sentiment about having to be frugal because of wasteful frameworks. My approach is to prefer libraries over frameworks. I start out using the most bare-bones configuration possible (no frameworks, no ORM, no CMS, etc) and then I selectively add well maintained libraries created by people whose attitude I understand. I think code reuse is generally overrated, particularly when it comes to the rather trivial things that web frameworks do. This is probably not very helpful to you. I apologize.
- coolgeek 15y ago
  http://codeigniter.com/ http://codeigniter.com/
johnb 15y ago
That position of "no compromises" is probably why you're not writing a framework on which others depend. Complex software always involves compromises, especially general purpose frameworks used by a large population. Even if you're saying that only in performance there can be no compromises (but generally people who say things like no compromises don't bound those statements) it will cause large compromises in other areas, such a future feature development or long term maintainability and readability.
- fauigerzigerk 15y ago
  Perhaps you should leave comments about my personality to those who actually know me. But if you insist on talking about character traits, let me say this to you: People who don't know where to compromise and where not to comproise generally make bad software.
  - asomiv 15y ago
    Compromises from whose point of view? One man's good compromise is another man's bad compromise.
    - fauigerzigerk 15y ago
      All I can do is state my own point of view as clearly as I can. And my point of view is already a compromise. I didn't say make it as fast as possible even if you have to rewrite it in assembly. I didn't even say, don't write it in Ruby. All I said is don't make it significantly slower than it was before. That doesn't seem like such a big ask.
  - johnb 15y ago
    That's a fair call - I don't know you and I am speaking about character traits. I don't feel your original comment reflected a position on knowing where to (or not) compromise, you made a strong assertion to take one option off the table in all situations. In my experience, developers who are make blanket rules up front about what can and can't be changed in the future development of a system don't end up making much of value. That's just my perspective, and I apologise if I've misread your character.
DisposaBoy 15y ago
If that's taken as written then it's plain and simply impossible - no debate. I can understand that a significant slowdown might be a problem but otherwise it's just much ado about nothing really. What matters most is perceived performance degradation. I'd go as far as to presume? that most if not all people cannot actually the difference between an operation that takes (e.g) 100ms and one that takes 500ms yet when you look at the percentage difference it's clearly an unacceptable performance drop.