Hacker News Reader

Comment by llimllib | Hacker News Reader

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`

View on HN

C# 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/6ba67f23e58afdb80f6be868...

Downvoting this won't improve Go's performance :)

I 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

Java 21, naive implementation, javax.xml.stream.XMLStreamReader, 2015 MBP:

1.2s warm

1.6s cold

~700ms cold on a 7800X3D - maybe its time to upgrade my laptop.

Reply on news.ycombinator.com