So a detailed look at this it seems to be that because the progress dialog makes a Yield call to the event processing loop then between each update of the progress bar there are many timer messages getting processed. This takes some time and for reasons I can't quite explain the amount of time increases the longer the number of GPX points exported. So the progress bar gets progressively slower over time.
On Windows the solution is simple. Don't use wxGenericProgressDialog and use instead wxProgressDialog. This does not Yield because it uses the native Windows progress bar and then the entire export takes about 2 seconds on my test system. I need to check some GTK systems to see if it also will
work there. On systems that are GTK based the progress dialog may
work differently. Also, someone would have to test on a Mac too since progress dialog may be different there as well.
For systems that do not have a native progress bar feature there is no simple solution.