In a job, you can use "bare naked SQL", without procs, if you want. An SQL task in a job will do any SQL you want. It's generally better to execute your queries as procs, but if you need to test something else, you can do it this way.

If you need run time for each, you can add a logging command to each proc/script that you run. This will, of course, add a little overhead to the process, but it should be relatively minimal if you keep the log simple.

A better way to monitor performance is to run a trace on the server and see how much CPU, how much time, IO counters, etc., for your procs. You'll get a lot more data that way and it's quite often very eye-opening.