On Tue, Feb 4, 2014 at 3:57 PM, Thomas <t.tchorzew...@gmail.com> wrote:
> Wow...Thanks Chris! I really appreciate your suggestions (including the
> stylistic ones). I'll definitely be revising my code as soon as I find the
> time. As far as profiling goes, I've used timeit in the past but it's quite a
> pain going through any program block by block. I wish there were a program in
> which you could just toss in a script and it would spit out the bottlenecks
> in your code (with suggested performance improvements perhaps)...
>
Well, timeit is good for microbenchmarking. (How useful
microbenchmarking itself is, now, that's a separate question.) For
anything where you can "feel" the program's time by human, it's easy
enough to use the time.time() function.
Add a little helper like this (untested):
last_time = time.time()
def tt(desc):
global last_time
cur_time=time.time()
print("%s: %f"%(desc,cur_time-last_time))
last_time=cur_time
Then put this all through your code:
....
# Calculating the length of data to collect based on the
# sample time and simulation time (set by user)
max_length = sim_time/sample_time
tt("Init")
# Collecting the data from the serial port
while True:
data_log.append(connection.readline())
if len(data_log) > max_length - 1:
break
tt("Serial")
...
etc etc. Give it a short description saying what's just happened
(because it'll give the time since the previous timepoint), and then
just eyeball the results to see where the biggest numbers are. If you
do it right, you'll find a whole pile of sections with tiny numbers,
which you can easily ignore, and just a handful that even register.
Then you dig into those sections and see where the slowness is.
Be careful, though. You can easily waste hundreds of expensive dev
hours trying to track down an insignificant time delay. :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
