Substantially edited, since the original poster changed his equation...
In general, the MATLAB (and Octave) ODE solvers dynamically adjust the step size as needed to maintain an accurate solution. If the integrator starts to use smaller step sizes then the process slows down.
Looking at the particular form of your ODE, the $\sin(wt)$ factor has a period of about 0.003, so substantially smaller time steps will be required. It's also smart to put in a maximum time step limit to stop the solver from stupidly deciding to use too large a time step. A time step of 0.0001 (1.0e-16/U) seems about right to me for this problem, and that's what the code given by the OP uses, along with a maximum time step of 0.0004 (4e-16/U).
We're interested in solving this equation for time spans of up to 1000 (1000/U), so we're looking at taking ten million steps or so (more if the solver decides that it needs to cut the time step.) Given that we have to evaluate the function multiple times per time step and all of the other overhead of the ODE solver, this is a fair bit of work.
I tried running the script under MATLAB for periods of 1, 10, 100, and 1000, and got completely consistent solutions with elapsed times of 0.3
seconds, 3.8 seconds, 32, seconds, and 322 seconds. This scales linearly,
so it doesn't appear that the solver got bogged down taking tiny time steps.
In order to check the accuracy of the solution, I tried decreasing the max time step by a factor of 10 and reran. I got essentially the same solutions, in elapsed times that were about 10 times longer. Thus I'm confident that the supplied initial time step and maximum time step are OK and the solution produced by MATLAB is reasonably accurate (to say 2 digits.)
I also tried allowing a larger maximum time step and found that MATLAB's ode23() was tricked into taking steps that were too long and the resulting solution (although very fast) was completely inaccurate. You need to be careful with limiting the maximum time step for this equation because of the fast oscillation in the equation.
I also tried tightening the relative and absolute error tolerances to 1.0e-3 (MATLAB's default) from 1.0e-1. The solutions were very similar but the solution times roughly doubled.
I ran some quick checks using ode45 instead of ode23 and got essentially the same solutions, but the execution time was about twice as long. This isn't surprising, since we're time step limited and ode45 does about twice as many function evaluations per time step as ode23.
I ran the script on the same machine under Octave, and the runs took 1 second, 10 seconds, 166 seconds, ... (the last one is still running after more than 45 minutes.) The solutions I obtained looked very similar to the MATLAB solutions which is good. However, this is not scaling linearly, indicating to me that the Octave implementation of ode23 is probably shortening the time step when it really doesn't have to.
I'd recommend that you give this example to the developers of the Octave ODE package and ask them to look into the poor performance in comparison with MATLAB ode23().