12-04-2022, 01:48 PM
One Steve Note with regards to LCASE$ and UCASE$ -- They're string manipulation functions, and as such, they're relatively sloooow in processing. Judicious and limited use of them is advised whenever they may be called upon heavily.
Let me give an example of what I'm speaking of:
Now, the above is a yucky bubble sort to begin with, but let's overlook that as it's just for the sake of an example. Inside that nasty bubble sort, we're using LCASE$ over and over and over and over and over some more, just to compare and sort our array. All these calls to LCASE$ are going to end up bogging down an already slow process (bubble sorts are quick and easy to write, but not very efficient at all) -- maybe pushing it to the point of unuseability. After all, who wants to sit there for an hour, waiting on some list to sort itself out in alphabetical order??
A better solution, in a case like this, is to minimize the usage of that slow processing string command, as much as possible.
More coding for the programmer, but the difference in performance is going to be very noticeable. Here, I simply made a temp array to hold all the elements of our normal Array, and I made them all lowercase *ONCE* for comparison usage. The first routine made calls to LCASE$ twice each loop, and repeated that same process over again a second time for the outer loop.
UBOUND(Array) number of calls to LCASE$ in the second set of code.
2 * UBOUND(Array) * UBOUND(Array) number of calls to LCASE$ in the first set of code.
Say there's 1,000,000 elements in that array... The second routine calls LCASE$ 1,000,000 times... The first calls it 2,000,000,000,000 times!!
Since it's already a generally slow process due to being string manipulation, can you imagine the difference in the speed and performance in those two routines??
Use LCASE$ and UCASE$ when you need them; just use them wisely and judiciously -- especially if your program is running slower than you'd like and you need to improve speed and performance with it.
Let me give an example of what I'm speaking of:
Code: (Select All)
FOR x = 0 TO UBOUND(Array)
FOR y = 0 TO UBOUND(Array)
IF Lcase$(Array(x)) < Lcase$(Array(y)) THEN SWAP Array(x), Array(y)
NEXT
NEXT
Now, the above is a yucky bubble sort to begin with, but let's overlook that as it's just for the sake of an example. Inside that nasty bubble sort, we're using LCASE$ over and over and over and over and over some more, just to compare and sort our array. All these calls to LCASE$ are going to end up bogging down an already slow process (bubble sorts are quick and easy to write, but not very efficient at all) -- maybe pushing it to the point of unuseability. After all, who wants to sit there for an hour, waiting on some list to sort itself out in alphabetical order??
A better solution, in a case like this, is to minimize the usage of that slow processing string command, as much as possible.
Code: (Select All)
DIM tempArray(UBOUND(Array)) AS STRING
FOR i = 0 TO UBOUND(Array)
tempArray(i) = LCASE$(Array(i))
NEXT
FOR x = 0 TO UBOUND(tempArray)
FOR y = 0 TO UBOUND(tempArray)
IF tempArray(x) < tempArray(y) THEN SWAP tempArray(x), tempArray(y)
NEXT
NEXT
FOR i = 0 TO UBOUND(Array)
Array(i) = tempArray(i)
NEXT
More coding for the programmer, but the difference in performance is going to be very noticeable. Here, I simply made a temp array to hold all the elements of our normal Array, and I made them all lowercase *ONCE* for comparison usage. The first routine made calls to LCASE$ twice each loop, and repeated that same process over again a second time for the outer loop.
UBOUND(Array) number of calls to LCASE$ in the second set of code.
2 * UBOUND(Array) * UBOUND(Array) number of calls to LCASE$ in the first set of code.
Say there's 1,000,000 elements in that array... The second routine calls LCASE$ 1,000,000 times... The first calls it 2,000,000,000,000 times!!
Since it's already a generally slow process due to being string manipulation, can you imagine the difference in the speed and performance in those two routines??
Use LCASE$ and UCASE$ when you need them; just use them wisely and judiciously -- especially if your program is running slower than you'd like and you need to improve speed and performance with it.