Changes between Initial Version and Version 1 of Ticket #11309, comment 41


Ignore:
Timestamp:
05/14/12 19:01:29 (7 years ago)
Author:
kini
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #11309, comment 41

    initial v1  
    11Done! Glad you like the comments :)
    22
    3 I did not do any timing, no. I'm not sure what you mean by "lines 1241ff", but function calls should typically be avoided if you're optimizing for speed, afaik. The main thing I was wondering was, the argument `op` to the function `_richcmp_c_impl()` is an integer, but `operator.*` as seen in lines 1245-1252 seem to be strings, if I'm not mistaken. So I'm just wondering if that many string operators for a single comparison of symbolic expression couldn't be better optimized by somehow getting the operator of the lhs and rhs of the big relation as integers rather than strings. Well, not to mention that I'm calling `.operator()` a bunch of times, but I don't know if it would actually be any faster to compute it once and store it in a variable.
     3I did not do any timing, no. I'm not sure what you mean by "lines 1241ff", but function calls should typically be avoided if you're optimizing for speed, afaik. The main thing I was wondering was, the argument `op` to the function `_richcmp_c_impl()` is an integer, but `operator.*` as seen in lines 1245-1252 seem to be strings, if I'm not mistaken. So I'm just wondering if that many string operations for a single comparison of symbolic expression couldn't be better optimized by somehow getting the operator of the lhs and rhs of the big relation as integers rather than strings. Well, not to mention that I'm calling `.operator()` a bunch of times, but I don't know if it would actually be any faster to compute it once and store it in a variable.
    44
    55They say you shouldn't try to second-guess compilers... I guess the best way to find out is to try a few different ways and see how `timeit` behaves. I'll do that later, I guess...