My work on this is now in the central repository, and I'm turning to
Performance in formatting floats is less than it was around 2.7b1,
but I don't see how we can correctly do better without writing our
own dtoa(). I looked into some examples using JVisualVM, and that's
where the time is going, mostly in BigDecimal. There may still be a
bit of mileage in optimising other stuff.
Generally, conformance with CPython is improved. Floats of course,
and some obscure things: I mean, who knew that '%6%' % () was '
In related conversations (can't find it now) I believe Jim asked if
this work would fix the instability in test_strtod. The answer seems
to be no. I think that's a str->float problem, but it's a mystery
to me why it fails sometimes and not always.
On 07/05/2014 22:41, Jeff Allen wrote:
Thanks Jim. I've had reasonable
success getting the float %-formatting cases covered by the new
FloatFormatter (to save us two skips). I'll try an
IntegerFormatter along the same lines, to fix the oddness I
noted, and make the refactoring neat.
I've no intention of replacing the switch here, but I'll look
out where I may be better off using one to choose between
actions. I understand how it compiles.
I agree non-BMP codepoints would not be an issue unless maybe
you put one where a formatting type was expected.
On 05/05/2014 00:16, Jim Baker wrote:
I'm glad you are looking at this! In looking at
StringFormatter, I agree with your refactoring plan.
StringFormatter grew by accretion, and at this point it's
quite hard to follow.
The current method StringFormatter of using a driving
switch statement for its format string interpreter remains
the fastest way to dispatch in Java. However, it will be
both more inlineable by the JVM and more testable by us if
we breaking out each chunk of work into its own small
Another thing: although peek/push/pop mechanism in
conjunction with index is not codepoint aware and just uses
format.charAt, this doesn't matter in the end. This is
because the format characters are all in the BMP - and in
fact are ASCII. So we can continue to use charAt. However, I
would recommend also splitting this functionality into a
small helper class, for the above inlining/testing reasons.
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
Jython-dev mailing list