The encoding/xml package provides a medium-level xml.Decoder type. That lets you read through an XML input stream one Token at a time, not unlike the streaming Java SAX model of old. When you find the thing you're looking for, you can jump back into decoder.Decode to run the normal unmarshaling sequence to get individual objects out. Just remember that the token stream might contain several things that are "irrelevant" (whitespace-only text nodes, processing instructions, comments) and you need to skip over them, while still looking for things that are "important" (non-whitespace text nodes, unexpected start/end elements).
As a high-level example, if you're expecting a very large SOAP message with a list of records, you might do a "streaming" parse until you see the <soap:Body> start-element, check that its immediate child (e.g., the next start-element) is the element you expect, and then call decoder.Decode on each of its child elements. If you see the end of the operation element, you can unwind the element tree (you now expect to see </soap:Body></soap:Envelope>). Anything else is an error, that you need to catch and process.
The skeleton of an application here might look like
type Foo struct {
Name string `xml:"name"`
}
decoder := xml.NewDecoder(r)
for {
t, err := decoder.Token()
if err != nil {
panic(err)
}
switch x := t.(type) {
case xml.StartElement:
switch x.Name {
case xml.Name{Space: "", Local: "foo"}:
var foo Foo
err = decoder.DecodeElement(&foo, &x)
if err != nil {
panic(err)
}
fmt.Printf("%+v\n", foo)
default:
fmt.Printf("Unexpected SE {%s}%s\n", x.Name.Space, x.Name.Local)
}
case xml.EndElement:
switch x.Name {
default:
fmt.Printf("Unexpected EE {%s}%s\n", x.Name.Space, x.Name.Local)
}
}
}
https://play.golang.org/p/_ZfG9oCESLJ has a complete working example (not of the SOAP case but something smaller).
XML parsing in Go, like basically everything else, is a "pull" model: you tell the reader what to read and it gets the data from the io.Reader you give it. If you manually create an xml.Decoder you can pull one token from a time from it, and that will presumably call r.Read in digestible chunks, but you can't push tiny increments of data into the parser as you propose.
I can't specifically speak to the performance of encoding/xml, but a hybrid-streaming approach like this will at least get you better latency to the first output and keep less live data in memory at a time.