On Wed, Oct 15, 2014 at 12:47:01AM -0000, Father Chrysostomos wrote: > Dave Mitchell wrote: > > I want to discuss some modest proposals for better testing of performance > > and optimisations. The first four suggestions are simple, concrete, and (I > > hope) non-controversial. The fifth is more woolly and up for discussion. > > What you propose all sounds good to me, but please consider the > following: > > As you can see, I recently added t/op/opt.t, because I was tired of > tweaking B::Concise expected output and because simple optimisations > have been broken in the past. > > How would that fit into your scheme? Should we just move it to t/perf > and just give it a more descriptive name? I wasn't aware of it (my ISP broke my mail and managed to get me unsubscribed from perl5-changes, which I didn't notice for a few days) I suspect some of the things that you're testing in that file could be tested even more easily with my count scheme, but it seems reasonbable having a test file that can check for specific structures in the optree. So I would rename t/op/opt.t to t/perf/optree.t say. > Also, another broken optimisation that comes to mind is in-place lc > and uc, which we currently have no way to test. Would it be a good > idea to add a test file that uses -D output to test optimisations (and > add some -D output for in-place lc)? There is one that tests regexp > compilation like that already, though I don't remember its name. Possibly ext/re/t/regop.t, and others in the same dir? Yes, I think a test file under t/perf/ that allows you to check -D output would be good. NB - I'm not aware what the specific issue was was in-place uc/lc. -- My get-up-and-go just got up and went.Thread Previous | Thread Next