On Thu, Nov 15, 2012 at 03:58:57PM -0500, James Antill wrote: > On Thu, 2012-11-15 at 11:02 -0800, Toshio Kuratomi wrote: > > I then removed the additional flexibility that the code had and pushed it > > into the yum.misc file as a replacement for _ugly_utf8_string_hack() and > > to_xml(). Benchmarking that was marginally faster than the code with the > > patches suggested here (once again, with greater variance between the test > > runs than between the different versions of the code). > > So I initially just tried the patch and got a time of 6:14 ... which > seemed pretty bad compared to the initial 1:25, 0:33 after my hack and > even with a super version of Zdenek's fix (translating in all code > paths) of 0:48. > But trying to see why didn't show anything and then I added: > > item = to_utf8(item) > > ...before the call to saxutils, as we do now. That gave a time of 0:37, > so ... news at 11 all xml libs. suck all the time. > James and I took a look at this today... but so far I've been unable to reproduce. I'd like to understand what's going on because it could be that moving the conversion to utf8 is just masking an issue for the specific cases that we have... leaving them to recur with other data.
Also -- in kitchen, the conversion to bytes is deliberately done below the call to saxutils.escape otherwise there are times when some portion of strings are escaped twice. I think that the yum code won't run into this since it is specific about using utf-8 and that bug occurs when converting to an encoding that doesn't cover every unicode codepoint but I like to keep things in the right order in case someone else modifies the code in the future. If I can't replicate it tomorrow I'll just move the to_utf8() step and we'll call it good enough. -Toshio
pgppSkByHhwW6.pgp
Description: PGP signature
_______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
