Custom Query (121 matches)
Results (49 - 51 of 121)
|#12||fixed||PyYAML is slow||xi||edemaine@…|
Here are two simple wall-clock timings comparing PyYAML to PySyck on a Pentium 4 2.8GHz with 1MB cache and 1GB RAM:
$ wc file1.yaml 2036 8767 59154 file1 $ test.py file1.yaml 0:00:00.001419 to read the YAML via Syck 0:00:04.029627 to read the YAML via PyYAML $ wc file2.yaml 8949 35105 317342 file2 $ test.py file2.yaml 0:00:00.001564 to read the YAML via Syck 0:00:19.288912 to read the YAML via PyYAML
I do not expect PyYAML to be terribly competitive with Syck: the language barrier is big, and PyYAML is written with a higher level of abstraction. But I was surprised to see a factor of 12,000 difference. I wonder if a bit of profiling and tuning might reduce this gap to just a couple of orders of magnitude (100x) instead of four? Personally, 19 seconds to read a 0.3 meg file is too slow for my application, so I'll have to switch back to Syck for now, unfortunately. Just food for thought...
|#30||fixed||Timestamp support has floating-point roundoff||xi||edemaine@…|
>>> import yaml, datetime >>> yaml.dump(datetime.datetime(2005, 7, 8, 17, 35, 4, 517600)) '2005-07-08 17:35:04.517600\n' >>> yaml.load(_) datetime.datetime(2005, 7, 8, 17, 35, 4, 517599)
This breaks the desired rule that yaml.load(yaml.dump(x)) == x in a case where there should be no roundoff. (datetime.datetime uses integers everywhere to avoid any error.)
The offending code seems to be line 321 in yaml/constructor.py:
fraction = int(float(values['fraction'])*1000000)
This seems to be an "easy" way to convert the trailing '.517600' into an integer, but it can go beyond floating-point precision. Wouldn't the following work?
fraction = int(values['fraction'][:6].ljust(6, '0'))
|#31||fixed||PyYAML for Python 2.5||xi||edemaine@…|
Could you compile a Windows binary of PyYAML for Python 2.5 (released fairly recently)? Ideally with libyaml support built in...