Despite it being used for virtually everything, and despite it being used even in high-volume, low-latency applications, XML is an abysmal format for almost everything, but in particular for applications that have timely constraints, including games (except maybe for storing the game's settings). Even for live data, a simple binary tagged format which basically does the same as XML, just not human-readable (say, a 16-bit node type, 32-bit length, followed by contents), will be many times faster to read and write.
XML is tempting because it is human readable, and you don't need more tools than a text editor to write an XML file. However, it is also overly verbose, doesn't handle several types of data (binary data, large amounts of numbers, etc.) too well, and it takes a very non-neglegible time to process.
You can speed up parsing considerably by using a different parser, there are many alternatives (rapidxml, pugixml, whatever), however, that does not address the general problem of the format being overly verbose and human-readable to begin with.
While it is acceptable, and not even too uncommon, to use XML in one's production pipeline (though most people would rather use JSON or YAML), normally there is a custom-made tool that runs during the build process and that converts your XML files to a proprietary binary format which can ideally (not necessarily, but ideally) simply be loaded or memory-mapped as-is. No parsing whatsoever, just memory map, and set a pointer.
That same tool (or a similar one) will usually also read in other data such as e.g. textures which are stored in a variety of formats that may also be non-trivial to parse, and also put them into a binary game file in a way so they can just be mapped ready-to-go.
With the correct format, loading should be rather 0.45 seconds than 45 seconds.