4 ms·
There's a minor but important point: the amount of work str() has to do depends on its input type. In particular, if arg.__str__() returns a string or a subtyp
by kmod 6y ago
There's a minor but important point: the amount of work str() has to do depends on its input type. In particular, if arg.__str__() returns a string or a subtype of string or not a string, str() will call different tp_init functions. So we can't get rid of the args tuple until after the optimization of knowing that arg.__str__() returns an string (which is why I did them in that order). So I guess the condition is a little bit weaker than str(int) but it's more than str() of one arg.
- burfog 6y agoI think you've proven that the language is a lost cause. It's never going to perform OK. With all the breakage of Python 3, it's a shame that the causes of slowness were not eliminated. The language could have been changed to allow full ahead-of-time compilation, without all the crazy object look-up. Performance might have been like that of Go.
- khc 6y agothen it will become perl6 which no one uses
- lizmat 6y agoPerl 6 is mostly not used because it has been renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). Raku is very much being used. If you want to stay up-to-date with Raku developments, you can check out the Rakudo Weekly News https://rakudoweekly.blog https://rakudoweekly.blog
- acqq 6y agoI'm still very sure that the Python's source code can be refactored to avoid the allocation completely in the case of a zero or one parameter for all the functions that now always have an expectation of the tuple. But I also understand that you can't achieve that in your case without changing the existing code base.