3 ms·
I reran the results on my m1 mac pro since this post is 6 years old: python etree: 3.25s python lxml: 2.01s go stdlib: 3.35s go gosax: 1.45s
by llimllib 2y ago
I reran the results on my m1 mac pro since this post is 6 years old:
python etree: 3.25s
python lxml: 2.01s
go stdlib: 3.35s
go gosax: 1.45s
C: 0.38s
So, python etree gives the same result 6 years on while lxml has gotten faster. Go's standard library does about as well as python's stdlib, and has gotten faster on the cgo binding.
Procedure:
- clone https://github.com/eliben/xmlgen
- run `xmlgen -f 2 > out.xml` to generate a test xml file
- clone https://github.com/eliben/code-for-blog/ and switch to the 2019/xml-stream dir
- mv out.xml from above to the current directory
- `time python etree-count.py out.xml`
- `pip install lxml && time python lxml-count.py out.xml`
- `go build go-stdlib-count.go && time ./go-stdlib-count out.xml`
- `cd c-libxmlsax-count && make && time ./c-libxmlsax-count ../out.xml`
- `cd gosax-count && go build gosax-count-simple.go && time ./gosax-count-simple ../out.xml`
- deleted 2y ago[deleted]
- neonsunset 2y agoC# takes 0.55s on M1 Pro with relatively ancient and not most optimized System.Xml.XmlReader: ./xmlgen -f 2 > dotnet/out.xml cd dotnet && dotnet publish -o . time ./XMLParse out.xml https://gist.github.com/neon-sunset/6ba67f23e58afdb80f6be868953a5ee4 https://gist.github.com/neon-sunset/6ba67f23e58afdb80f6be868...
- neonsunset 2y agoDownvoting this won't improve Go's performance :)
- eadmund 2y agoI wrote this quick little program on my laptop: (ql:quickload "cxml") (defclass finder (sax:default-handler) ((in-location :initform nil) (count :initform 0))) (defmethod sax:start-element ((finder finder) namespace-uri local-name qname attributes) (setf (slot-value finder 'in-location) (string= local-name "location"))) (defmethod sax:characters ((finder finder) data) (when (and (slot-value finder 'in-location) (search "Africa" data)) (incf (slot-value finder 'count)))) (let ((finder (make-instance 'finder))) (cxml:parse #P"out.xml" finder) (slot-value finder 'count)) and got: Evaluation took: 5.316 seconds of real time 5.339639 seconds of total run time (5.330888 user, 0.008751 system) [ Real times consist of 0.032 seconds GC time, and 5.284 seconds non-GC time. ] [ Run times consist of 0.049 seconds GC time, and 5.291 seconds non-GC time. ] 100.45% CPU 8,547,510,059 processor cycles 1,082,877,232 bytes consed For comparison: python etree: 3.04s python lxml: 3.65 go stdlib: 5.18 go gosax: 2.37 C: 0.54 Really disappointing that the Common Lisp version performs worse and is less readable than the Python lxml version. This one is more readable, but even slower: (klacks:with-open-source (s (cxml:make-source #P"out.xml")) (loop for key = (klacks:peek s) with count = 0 while key when (and (eq key :start-element) (string= (klacks:current-lname s) "location")) do (progn (setq key (klacks:peek-next s)) (when (and (eq key :characters) (search "Africa" (klacks:current-characters s))) (incf count))) do (klacks:consume s) finally (return count))) It gets: Evaluation took: 9.996 seconds of real time 10.054716 seconds of total run time (9.979712 user, 0.075004 system) [ Real times consist of 0.092 seconds GC time, and 9.904 seconds non-GC time. ] [ Run times consist of 0.101 seconds GC time, and 9.954 seconds non-GC time. ] 100.59% CPU 16,077,773,140 processor cycles 2,338,978,688 bytes consed
- MrBuddyCasino 2y agoJava 21, naive implementation, javax.xml.stream.XMLStreamReader, 2015 MBP: 1.2s warm 1.6s cold
- MrBuddyCasino 2y ago~700ms cold on a 7800X3D - maybe its time to upgrade my laptop.