On Mon, 1 Mar 2010 04:11:07 -0800 (PST) simn_stv <nany...@googlemail.com> wrote: > > All of the above (and much more complexity not even discussed here) was > > handled by Python code and database manipulation. There were a few > > bumps along the way but overall it worked fine. If we were using C or > > even assembler we would not have sped up anything and the solution we > > came up with would have been horrendous to code. As it was I and my > > chief programmer locked ourselves in the boardroom and had a working > > solution before the day was out. > > sure it wouldnt have sped it up a bit, even a bit?; probably the > development and maintenance time would be a nightmare but it should > speed the app up a bit...
What do you mean by "even a bit?" The bulk of the time is in sending bits on the wire. Computer time was always negligible in this situation. Yes, I can write all of my applications in assembler to get a 0.00000000000001% increase in speed but who cares? If you have decent algorithms in place then 99% of the time I/O will be your bottleneck and if it isn't then you have a compute heavy problem that assembler isn't going to fix. And even if I get a 100% increase in speed, I still lose. Computer time is cheaper than programmer time by so many orders of magnitude that it isn't even worh factoring in the speedup. -- D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
