I’ve just tried to compare execution time between two different approaches to the same exercise. Doing this manually is not very accurate.
Would it be possible to add the total execution time to the Scrubber’s UI?
It depends a little what you mean by execution time. Do you mean how long the animation takes to play out (e.g. in Space Invaders whether you’ve got the most efficient shooting+moving algorithm), or how much CPU/memory is used in generating it - ie how efficient your code is?
I can do the first, but not really the second. Benchmarking CPU/memory is only really useful if you run the same code multiple times and compare, which you don’t want to do in this situation as it’ll be slow.
The key thing to understand around this is that you’re not really seeing your code execute in the bottom left, you’re seeing a video of it executing.
1 Like
It was to compare two different ways of drawing the skyscraper, i.e. the algorithm that was used. One involved lots of individual calculations, whereas the other was heavily reliant on loops and far fewer calculations. I was just interested to see if one approach was faster than the other. Not interested in CPU / memory efficiency per se, just how long it takes to finish the drawing 
You could work this out yourself actually by reading your code. Maybe Ask Jiki to teach you about Big O Notation to compare solutions (someone else with more time might chip in too! 
)
1 Like
That was a fantastic suggestion!
After going down the rabbit hole I came up with the answer I was looking for 
Talk to Jiki was a little bit funny about helping me. This surprised me as I’ve been using it a lot over the last few days (sorry, I nearly hit the daily fair use limit the other day!). This time round Jiki gave me a definition of Big O Notation but then said:
For now, let’s keep our focus on successfully building the skyscraper in this exercise.
Which of course I’d already done - but Jiki didn’t like the column by column approach and kept asking me to justify my code decisions. I think Jiki expected to see a floor by floor approach, and was trying to learn how a column by column approach could also work. Interesting, but not what I was after
So I then read Chapter 13 on “Measuring Performance and Big O Algorithm Analysis” from Al Sweigart’s “Beyond the Basic Stuff with Python”. I only know a little Python, but this was enough to get the gist of the chapter’s material.
I was then able to analyze both programs and come up with 6n + 12 for the floor by floor program, and 8n + 8 for the column by column program.
At this point, I turned to ChatGPT to do its own analysis and I was pleasantly surprised to see it came up with the same results that I had come up with manually 
ChatGPT was able to conclude that the floor by floor approach was nearly always more efficient than the column by column approach. This was because for any skyscraper with more than 2 floors, the floor by floor approach would always execute fewer steps to draw each floor than the column by column approach.
Thanks Jeremy! That was such a helpful nudge to go learn something new
3 Likes
Why would floor-by-floor have fewer steps? Isn’t there always the same number of squares that need drawing?
1 Like
Both programs draw the same number of squares, but the process by which they draw them is different.
My floor by floor approach takes 6 steps to draw each floor. I use only 1 loop that is dependent on the number of floors.
My column by column approach takes 8 steps to draw each floor. This is because the program uses 3 loops that are dependent on the number of floors, so there are 2 extra steps that need to take place - both are where I increase or decrease my Y coordinate.
If you want to see both my programs, I’ve posted them in Discuss Your Solutions:
The number of loops doesn’t particularly matter. One loop that does 5 steps per loop or five loops that does one step each are both the same: 1 * 5 == 5 * 1. Both approaches ought to be calling build<Thing> five times per floor.
Big-O notation is asymptotic, which is a fancy way of saying it ignores multipliers and other terms. It is expressed in terms of n, the size of the data.
Both 6n + 12 and 8n + 8 have the same time complexity (this is the technical name), which is O(n), meaning they are both proportional to the size of the data: if it takes 1s to run for a dataset of 1000, it should take roughly 2s to run for a dataset of 2000.
This notation is just an approximation so we can have some intuition about the behaviour of an algorithm. In practice, there are tons of factors that influence these times.
Both your algorithms are roughly equivalent. They do basically the same amount of work. Counters, like those that you use to increase the Y coordinate, are essentially free on most situations.
I wouldn’t worry too much about “efficiency” right now. Having fun and exploring things is much more important.
1 Like
Be aware that you’re also now probably half way to the monthly fair use 
With all of this - great work with experimenting, playing, learning. You will bode very well in this field with this attitude! 
1 Like
I already guessed that would be the case… I’m trying to word my questions more precisely, so I don’t end up in long conversations
1 Like
But on a serious note, I really appreciate you testing that the “close to your allowance” message works 
1 Like
Well of course that was my intention all along 
1 Like