On Tue, May 14, 2013 at 7:43 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> Hi Nikita, > > Few final notes: > > - I wouldn't change zend_object_compare_t into > zend_object_compare_objects_t. It would be better to name the new function > as zend_object_compare_zvals_t. (It's just for better backward > compatibility) > Done. Should I also call the handler itself compare_zvals then or can that stay as just compare? - Increment and decrement operators in PHP may have different semantic than > +=1, but I it's probably OK to use ADD/SUB for them. > I think we should just introduce this once a use case comes up. > - In some cases you insert call to zend_object_do_operation into the most > probable path (e.g. in mod_function). This would cause at lease 2 > additional comparisons and may be conditional jumps. I think it would be > better to check for most probable operand types first... > For $a % $b the most common cases are already handled by fast_mod_function. mod_function is only directly called when doing $a %= $b. But in any case, I'm not sure how I could test the more probable cases first, as the next thing the code does is call convert_to_long. Of course I could copy the code from fast_mod_function in there, but that doesn't sounds like a good idea. I think the only operation that could really be a performance concern is concat_function, because that's a common operation without a fast_ variant. But even in that case I could not measure a difference in runtime (taking averages on 100M concatenations). > Also it may be better to use a table of callbacks for each overloaded > operand instead of single one that need to do switch anyway. > What would be the benefits? Better performance? Imho using a switch is handier when implementing the operators, because it requires less boilerplate code (no need to repeat function signature, variables, shared code etc). > Also it may make sense to think about overloading of unary operators to > provide a solid decision. > You mean being able to overload unary + and - directly rather than the current 0+$a / 0-$a transformation? I can see that this might be useful, but not sure it's worth it (would have to introduce new opcodes for that). I'd do the same as with the increment/decrement operators here: Only implement them once there is a specific use case. In case you think about user-level operator overloading in the future (that > may make sense :) it would be better to design them all together. > I was thinking about that too, but from the previous discussions on the topic I figured that there is zero chance for having that in PHP :/ Thanks for the feedback! Nikita
