GPX files are remarkably inefficient, in terms of the file sizes they produce. You can see this for yourself by zipping a GPX file, and comparing the size of the zipped file - it generally compresses to about 1/8th of the size, or even smaller.
But the huge file sizes you quote are a consequence of recording a lot of anciliary data (HR etc) and - I'm guessing - recording at a high frequency, possibly one point per second. I question the need for 1 point per second but I've been told it goes with the territory if you want to record HR and cadence etc. Otherwise, one point per 5 seconds would be more than adequate I'd think, and your file sizes would shrink to 1/5th as a result.
Various online utilities can clean tracks but I think they would mostly baulk at being hit with a 45Mb file.
An advanced text editor with sophisticated wild-card search abilities might be able to remove selected anciliary data, if you have good regex skills (better than mine) by searching for <tag>***</tag>
Regarding stiching tracks together - I do a lot of this, though at the planning stage rather than after the event - nipping fragments of tracklog here and there, drawing joins, adding a section from a planner, etc. One thing to be careful of, is never to have a backward step in time. In other words, the timestamp (if present) must always be later than any preceding timestamp in the list. Seems obvious, but if you do a lot of stitching together it's easy to break this rule. It can result in data error messages (if you're lucky) or software/GPS crashes. If I manufacture a heavily-stitched track, I always play safe and strip the timestamps out (using Phil's utility, which also strips the elevations unfortunately) and then usually add the elevations back in (using GPS Visualizer).