Stefan Behnel added the comment:
+1. Does it give reasonably predictable timings?
--
___
Python tracker
<http://bugs.python.org/issue19236>
___
___
Python-bug
Stefan Behnel added the comment:
Another thing: you are only using one thread for both the client and the
server, and the app writes the entire content in one go (during one call to
get()). Wouldn't it be more interesting to make the app's get() method
asynchronous as well, so that
Stefan Behnel added the comment:
This commit conflicts with the patch for issue #19108 and breaks benchmarking
in Py3 (at least for me).
Traceback (most recent call last):
File "perf.py", line 2538, in
main(sys.argv[1:])
File "perf.py", line 2481, in main
Changes by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<http://bugs.python.org/issue16612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
-1 on any changes that make the specific C-API functions less specific. They
are perfectly adequate for gaining speed in well defined situations.
+0 on any changes that special case concrete types in abstract calls if they
prove to be worth the hassle.
+1 for
Stefan Behnel added the comment:
Nick Coghlan added the comment:
> Antoine Pitrou added the comment:
>> To be clear: the problem is with CPython calling the concrete APIs when
>> it shouldn't, rather than with the concrete APIs not behaving properly.
>
> The boiler
Stefan Behnel added the comment:
How about actually allowing a list in addition to a tuple? And, in fact, any
sequence? I can't see a reason not to.
For reference, lxml only expects it to be either None or an iterable.
Essentially, I consider it more of a set-like filter, since the l
New submission from Stefan Behnel:
The "tp_print" slot is still documented as it was in Py2, although it is no
longer used in Py3.
http://docs.python.org/3.4/c-api/typeobj.html?highlight=tp_print#PyTypeObject.tp_print
Given that it no longer serves any purpose, it should a
Stefan Behnel added the comment:
Brecht Machiels, 03.11.2013 11:58:
> With Python 3.2, I subclassed ElementTree.XMLParser to set
> ExternalEntityRefHandler on the XMLParser's (expat) 'parser' member
This sounds like a request for a missing feature to me. Here is how l
Stefan Behnel added the comment:
Thanks!
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue19609>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
If (as I assume) XML 1.1 isn't supported, then rejecting anything but "1.0"
would be correct.
Not for Py2.7 anymore, though, I guess, more something to fix for 3.4.
--
___
Python tracker
<http
Stefan Behnel added the comment:
This is a duplicate of issue17011.
--
___
Python tracker
<http://bugs.python.org/issue19862>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
Your code adds a lot of new code. Why is that necessary? Can't the new feature
be integrated into the existing code?
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
"you'd be surprised how much cheaper indexing a sequence is relative to
dictionary access"
This is a bit off-topic (and I realise that this ticket is closed now), but the
difference isn't really all that large:
$ python3.4 -m timeit -s &#
Stefan Behnel added the comment:
Ok. This has been idling long enough to just close it.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Stefan Behnel added the comment:
Even if there is no way to explicitly request a RO buffer, the Py_buffer struct
that you get back actually tells you if it's read-only or not. Shouldn't that
be enough to enable this optimisation?
Whether or not implementors of the buffer protoco
Stefan Behnel added the comment:
FWIW, functions in Cython (which C-level-inherit from PyCFunction) support weak
references just fine. Adding that as a general feature to PyCFunction sounds
like the right thing to do.
--
nosy: +scoder
___
Python
Stefan Behnel added the comment:
Patch looks ok. Not sure about the test dependency from test_weakref.py to
_testcapi, though. Is that module allowed to be used everywhere? Wouldn't it be
enough to test that one of the builtin functions is now weak referencible?
"len" seem
Stefan Behnel added the comment:
Looks like a duplicate of issue 17781. Ubuntu already does this for their
builds and gets substantially better performance, so I can't see a reason why
CPython shouldn't just follow.
--
nosy: +scoder
Stefan Behnel added the comment:
> (for the record, the context is that we would like to support decimal objects
> efficiently in Numba)
Same for Cython, although I guess we wouldn't do more than shipping the
necessary declarations and (likely) also enable auto-coercion between th
Stefan Behnel added the comment:
The current implementation doesn't work with Unicode file paths. Try passing a
Unicode string e.g. as "cafile" into context.load_verify_locations(). It calls
PyString_AsEncodedObject() on it, which then fails with a PyErr_BadArgument()
on the e
Stefan Behnel added the comment:
I'm now getting duplicated slashes in URLs, e.g.:
https://new//foo.html
http://my.little.server/url//logo.gif
In both cases, the base URL that gets joined with the postfix had a trailing
slash, e.g.
"http://my.little.server/url/"; + "
Stefan Behnel added the comment:
> Stefan (Behnel), could you comment on the strategy that you had in mind?
> Is it similar to module_get_symbol.diff or entirely different?
I agree with Antoine that a Capsule would work better here (and yes, the
performance problem of capsules is onl
Stefan Behnel added the comment:
I noticed this, too. I think it's due to the urllib changes in issue 22118.
--
components: +Library (Lib)
nosy: +pitrou, scoder
type: -> behavior
___
Python tracker
<http://bugs.python.org
Changes by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<http://bugs.python.org/issue20035>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Behnel:
"longintrepr.h" is a non-public header file (not included by Python.h) that
defines the inner struct layout of PyLong objects. Including it allows for very
fast access to "small" integers through ob_digit[0] when -1 <= Py_SIZE(n)
Stefan Behnel added the comment:
Were the tests in
http://bugs.python.org/file32591/urischemes.py
merged yet, that Nick Coghlan mentioned in
http://bugs.python.org/issue22118#msg225662 ?
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
CPython 3.5, latest development versions. This started failing on August 21st,
presumably with the changes for issue 22118.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Is this superseded by issue 22194 now or the other way round?
--
nosy: +scoder
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Yes, please. The sequential build in distutils is very annoying.
(too late for Py3.4, though, I guess...)
--
nosy: +scoder
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue5
Stefan Behnel added the comment:
Agreed that it's not a bug in CPython, but my guess is that it's not a bug in
NumPy either. The C function you call (which IIRC creates a new NumPy array)
almost certainly needs the GIL to protect it against race conditions, and since
you mentioned O
New submission from Stefan Behnel:
Fractions are great for all sorts of exact computations (including
money/currency calculations), but are quite slow due to the need for
normalisation at instantiation time.
I adapted the existing telco benchmark to use Fraction instead of Decimal to
make
Stefan Behnel added the comment:
I just thought that it might also be nice to have a direct comparison with
Decimal, so here's an updated benchmark that has an option "--use-decimal" to
run the same code with Decimal instead of Fraction.
Decimal is about 66x faster with Py3.4
Stefan Behnel added the comment:
As I said, where ever exact calculations are needed. I use them for currency
calculations, for example, as they inherently avoid rounding errors during the
calculations regardless of the relative size of values. They are basically like
Decimal but with
Stefan Behnel added the comment:
I admit that I keep meeting developers who are not aware of their merits,
simply because many other programming languages don't have them available.
Specifically, many developers with a Java background firmly believe that
BigDecimal is the only way to do
New submission from Stefan Behnel:
Fractions are an excellent way to do exact money calculations and largely beat
Decimal in terms of simplicity, accuracy and safety. Clearly not in terms of
speed, though.
The current implementation does some heavy type checking and dispatching in
__new__
Stefan Behnel added the comment:
Speed improvements for fractions should have their own ticket(s). I created
issue 22464 for this.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Adding Mark Dickinson to the noisy list who mentioned having worked on a C
implementation for gcd(). I think this would be a good thing to try. However,
the most important part would be to restructure and specialise
Fraction.__new__().
--
nosy
Stefan Behnel added the comment:
Here is a straight forward patch that special cases int values in the
constructor. It gives me a 35% speedup in the benchmark.
--
keywords: +patch
Added file: http://bugs.python.org/file36687/special_case_int.patch
Changes by Stefan Behnel :
--
type: -> performance
___
Python tracker
<http://bugs.python.org/issue22464>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Behnel added the comment:
Updated patch - there is a somewhat hidden attempt in the code to keep
nominator and denominater plain int values, not subtypes. That means that it's
safer to restrict the optimisation to plain ints as well, which should still
hit >95% of the u
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file36689/special_case_int3.patch
___
Python tracker
<http://bugs.python.org/issue22464>
___
___
Python-bug
Stefan Behnel added the comment:
The second isn't a big difference because it only hits plain instantiations
from integers. They are less likely to be performance critical than those from
a quotient, which happen for all calculations.
It's more for symmetr
Stefan Behnel added the comment:
I found one more place where special casing helps: equal comparisons to
integers, e.g. f == 0 or f == 1 or so. timeit shows me a speedup by a factor of
three for this, with only a tiny slow-down when comparing fractions on both
sides.
I put all of them in one
Stefan Behnel added the comment:
Benchmark profile after the patch:
5930670 function calls (5930288 primitive calls) in 3.748 seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
5196320.8280.0000.8280.000
Stefan Behnel added the comment:
Here is another little optimisation that removes the redundant property lookups
for the denominator in __add__() and __sub__().
New profile:
5291182 function calls (5290800 primitive calls) in 3.596 seconds
Ordered by: internal time
ncalls
Stefan Behnel added the comment:
This simple Cython variant of gcd() is substantially faster for me (you may
consider it pseudo-code for a C implementation):
def _gcd(a, b):
# Try doing all computation in C space. If the numbers are too large
# at the beginning, retry until they are
Stefan Behnel added the comment:
BTW, the last two patches (int4 and redundant_property) are ready to be
applied. Anyone?
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
I suggest adding a new implementation instead of replacing the current function
in the fractions module. As Mark noted, the current gcd() is more of a
sideeffect of the fractions module, but there's no real need to change that. It
works perfectly ok for a
New submission from Stefan Behnel:
fractions.gcd() is required for normalising numerator and denominator of the
Fraction data type. Some speed improvements were applied to Fraction in issue
22464, now the gcd() function takes up about half of the instantiation time in
the benchmark in issue
Stefan Behnel added the comment:
I created issue 22486 about the gcd() performance. I think we can close this
ticket - I don't see any more obvious low hanging fruit and future findings can
have their own ticket.
Out of interest, I modified the fractions module to compile Fraction in
Stefan Behnel added the comment:
That's what the patch does anyway. +1
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
Also see issue 22486. There is an unmerged C implementation in the old issue
1682 that would go into the math module.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
http://bugs.python.org/file9486/lehmer_gcd.patch
(see #1682)
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Stefan Behnel added the comment:
The problem is that this changes the behaviour of fractions.gcd() w.r.t.
negative numbers. It's a public function, so we should keep it for backwards
compatibility reasons, *especially* when adding a new function in the math
module.
--
compo
Stefan Behnel added the comment:
Oh, and thanks for working on it, Serhiy! :)
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
The thing is, if we add something new in a substantially more exposed place
(the math module), then why break legacy code *in addition*? Just leaving it
the way it is won't harm anyone, really.
--
___
Python tr
Stefan Behnel added the comment:
IMHO, the most straight forward way for a new gcd() function to work would be
to always, predictably return a non-negative value and let users handle all
cases themselves where a negative sign of any or all input values has a
specific meaning to them. That&#
Stefan Behnel added the comment:
+1 for Mark & Terry, just for the record
--
___
Python tracker
<http://bugs.python.org/issue22477>
___
___
Python-bugs-list ma
Stefan Behnel added the comment:
Sorry for reopening this, but I found one more thing. Division is pretty heavy
on PyLong objects and there doesn't seem to be an internal optimisation for
division by 1 and -1. Since many Fraction input values can already be
normalised for some reason
New submission from Stefan Behnel:
The attached patch adds fast paths for PyLong division by 1 and -1, as well as
dividing 0 by something. This was found helpful for fractions normalisation, as
the GCD that is divided by can often be |1|, but firing up the whole division
machinery for this
Stefan Behnel added the comment:
I tried it, but it seems better to open a new ticket for this as there are
behavioural changes. See #22501.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Stefan Behnel added the comment:
Attaching a similar patch for long_mul().
--
Added file: http://bugs.python.org/file36730/mul_by_1_fast_path.patch
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
> Any optimization requires a benchmark. What is the speedup?
I gave numbers in ticket #22464.
"""
Since many Fraction input values can already be normalised for some reason, the
following change shaves off almost 3
Stefan Behnel added the comment:
@Serhiy: moving the fast path into l_divmod() has the disadvantage of making it
even more complex because we'd then also want to determine the modulus, but
only if requested, and it can be 1, 0 or -1, depending on the second value.
Sounds like a lot more
Stefan Behnel added the comment:
Combined patch for both mul and div that fixes the return value of
long_true_div(), as found by Serhiy, and removes the useless change in
long_divrem(), as found by Antoine. Thanks!
All test_long.py tests pass now.
--
Added file: http
Stefan Behnel added the comment:
@Serhiy: please ignore my comment in msg227599. I'll submit a patch that moves
the specialisation to l_divmod().
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
Thanks for the reviews, here's a new patch.
--
Added file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch
___
Python tracker
<http://bugs.python.org/issue22501>
___
___
Stefan Behnel added the comment:
Sorry, last patch version contained a "use before type check" bug.
--
Added file: http://bugs.python.org/file36733/mul_div_by_1_fast_path_3.patch
___
Python tracker
<http://bugs.python.o
Stefan Behnel added the comment:
Here is an incremental patch that adds fast paths for adding and subtracting 0.
Question: the module calls long_long() in some places (e.g. long_abs()) and
thus forces the return type to be exactly a PyLong and not a subtype. My
changes use a plain "i
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file36736/mul_div_by_1_fast_path_3.patch
___
Python tracker
<http://bugs.python.org/issue22501>
___
___
Pytho
Stefan Behnel added the comment:
Ok, updating both patches.
--
Added file: http://bugs.python.org/file36735/add_sub_0_fast_path_2.patch
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
I reran the fractions benchmark over the final result and the overall gain
turned out to be, well, small. It's a clearly reproducible 2-3% faster. That's
not bad for the macro impact of a micro-optimisation, but it's not a clear
argument for thr
Stefan Behnel added the comment:
Thanks, Serhiy. However, something is wrong with the implementation. The
benchmark runs into an infinite loop (it seems). And so do the previous
patches. Does it work for you?
--
___
Python tracker
<h
Stefan Behnel added the comment:
I compiled it with 30 bit digits, in case that's relevant. (It might be.)
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
This is what hangs for me:
math.gcd(1216342683557601535506311712, 436522681849110124616458784)
"a" and "b" keep switching between both values, but otherwise, the loop just
keeps running.
The old fractions.gcd
Stefan Behnel added the comment:
I can confirm that it works with 15 bit digits.
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bug
Stefan Behnel added the comment:
Since Serhiy gave another round of valid feedback, here's an updated patch.
--
Added file: http://bugs.python.org/file36739/mul_div_by_1_fast_path_3.patch
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
I callgrinded it again and it confirmed that the gain when doing this inside of
long_div() and friends is way lower than doing it right in Fraction.__new__().
It's not safe to do there, though, as "is" tests on integers are generally not
a good
Stefan Behnel added the comment:
Patch 7 works for me. Why are the two Py_ABS() calls at the end needed when we
start off the algorithm with long_abs()?
The Lehmer code is complex (I guess that's why you added the pure Euclidean
implementation), but it's the right algorithm to us
Stefan Behnel added the comment:
One more comment: I also benchmarked the change in long_true_div() now and
found that it's only a minor improvement for large numbers and a
*pessimisation* for small numbers:
Before:
$ ./python -m timeit -s 'x = 5' 'x / -1'
1000
Stefan Behnel added the comment:
My personal take is: if there is an implementation in the stdlib, it should be
the one that's most widely applicable. And that includes large numbers. We have
a working implementation that is algorithmically faster for large numbers, so I
can't
Stefan Behnel added the comment:
> That does seem odd -- how can you have 'b' of something?
Don't ask this kind of question as long as any math guys are listening.
But seriously, I consider this proposal reasonable. If the problem is that the
counter values can be non-inte
Stefan Behnel added the comment:
I'd raise an exception whenever the values of the Counter turn out to be
uncomparable. If users manage to fill Counters with non-number values that are
comparable amongst each other, or even if each key has a value of a different
type, why not just su
Stefan Behnel added the comment:
Any objections to merging the last patch?
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
There are not such changes in patch 7. The fractions.gcd() function is
unchanged but no longer used by the Fraction type, which now uses math.gcd()
internally instead.
--
___
Python tracker
<http://bugs.python.
Stefan Behnel added the comment:
+1
I mean, there is already such a type check in Fraction.__init__(), but I can
see a case for also optimising fraction.gcd() for exact ints.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Sure.
--
keywords: +patch
Added file: http://bugs.python.org/file36813/undocument_tp_print.patch
___
Python tracker
<http://bugs.python.org/issue19
Stefan Behnel added the comment:
> Proper escaping should be added to the _escape_attrib() function into
> /xml/etree/ElementTree.py (and equivalent for cElementTree).
Agreed. Can you provide a patch?
--
versions: -Python 2.7
___
Python t
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file36813/undocument_tp_print.patch
___
Python tracker
<http://bugs.python.org/issue19477>
___
___
Pytho
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file36815/undocument_tp_print.patch
___
Python tracker
<http://bugs.python.org/issue19477>
___
___
Python-bug
Stefan Behnel added the comment:
> it might be worth at least considering how a 'one or more parameter' gcd
> compares on performance grounds with a two parameter one.
There shouldn't be a difference in practice. The bulk of the work is in the
algorithm that finds the GC
Stefan Behnel added the comment:
I agree that this is an improvement, but isn't it a bit late for removing a
public field from a public header file in 3.4, without any preceding
deprecation?
--
nosy: +scoder
___
Python tracker
Stefan Behnel added the comment:
> what's the migration path for C API users that were relying on that struct
> field?
Depends on how you use it, I guess. In many cases (at least for Cython and
likely some other low-level tools), it could be as simple as
#if PY_VERSION_HEX &
Stefan Behnel added the comment:
> frameobject.h is not included in Python.h, so the
> classic #include "Python.h" doesn't give you access to PyFrameObject
> structure. You have to add a second #include "frameobject.h".
Ah, right. I keep misremembering that, be
Changes by Stefan Behnel :
--
nosy: +eli.bendersky, scoder
___
Python tracker
<http://bugs.python.org/issue17088>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
Note that the option is called "default_namespace", not
"default_namespace_prefix". Could you try passing the namespace URI instead?
--
___
Python tracker
<http://bug
Stefan Behnel added the comment:
*bump* - patch pending review.
--
___
Python tracker
<http://bugs.python.org/issue19108>
___
___
Python-bugs-list mailin
901 - 1000 of 1287 matches
Mail list logo
