Here are the time saving changes I made
Portion 1 - function getItem
- reduced size of “getItems” from 53 lines to 5 lines
- improved time complexity from linear to constant time
- How: by realizing that instead of moving an item from one location into another one by one until the new location was full, the current capacity of the new location (x) and the quantity of the current item (y) could be compared. Finding the absolute value of the difference between x and y could make this function run in constant time rather than linear time
evidence
new function(s)
getItem (calls “amountPlacedInBar” and “amountPlacedInInventory”)
amountPlacedInBar (calls “putInMatchingBarSlot” and “putInEmptyBarSlot”)
putInMatchingBarSlot (calls “minVal”)
putInEmptyBarSlot (calls “minVal”)
minVal (could’ve replaced with a ternary operator I realized)
amountPlacedInInventory (calls “putInMatchingInvSlot” and “putInEmptyInvSlot”)
putInMatchingInvSlot (calls “minVal”)
putInEmptyInvSlot(calls “minVal”)
old function
Analysis
- old function: 54 lines of code
- 29 lines of code, 25 blank lines, 0 comment lines
- new function: 137 lines of code
- 117 lines of code, 16 blank lines, 4 comment lines
- from 29 lines of code to 117 lines of code (4x the lines of code)
- from linear time complexity O(n) to constant time O(1)
- input size is the number of items that the player is holding
- gaining improved time complexity at the cost of worsened space complexity was a worthy trade-off
- Significance:
- Now, it takes the same amount of time to remove 64 of any item from an inventory slot as it does to remove 1 item.
- (eg. removing a stack of 64 porkchops and removing a single porkchop take the same amount of time)
- 64 is the maximum “input size” for the number of items that a player is holding in the game
- Player must frequently place and remove items in inventory
- By changing the time complexity from linear time to constant time, we avoid up to 63 unnecessary iterations EVERY time the player picks up or removes items from inventory
- this saves on computer processing power
Portion 2 - function wearingArmor
- improved time complexity from linear to constant time
function wearingArmor (called in fullInventoryPlatform)
- improved time complexity from linear to constant time
- How: by realizing that mapping from an itemID number to a number within 0 to 3 could be achieved with mod division (itemID % 4) rather than a subtracting loop that would subtract 4 from the item Id until the itemID fell within the bounds of 0 to 3 (inclusive)
evidence
helper function used in both (setTag)
new function(s):
old function (was not in a function, I had to put it inside a function)
Analysis
- old function (portion of code): 53 lines of code
- 27 lines of code, 26 blank lines, 0 comment lines
- new function: 51 lines of code
- 41 lines of code, 8 blank lines, 2 comment lines
- from 53 lines of code to 51 lines of code (inconsequential difference)
- from linear time complexity O(n) to constant time O(1)
- input size is the itemID of the item
- this goes up to ID 337
- Significance
- Now, it takes the same amount of time for the character to wear any piece of armor. Comparing the worst case scenarios for before and after, the modifications result in eliminating up to 336 additional iterations
Portion 3 - autoGrab and manualGrab
functions autoGrab and manualGrab
- encapsulated 2 sections of code into 2 functions
- removed two duplicated sections of code