lksseven wrote on Jan 31^st, 2012 at 9:32pm:


If you only want one record, set the result set position and get the value you want. Say you have a result set:

vCnt = @XResultSetTotal(vRS)
XResultSetCurrentPosition(vRS, 1)
vMinDate = @XResultSetValue(vRS, "OrderDate")
XResultSetCurrentPosition(vRS, vCnt)
vMaxDate = @XResultSetValue(vRS, "OrderDate")
 

Quote:

Yeah...I get that a lot.   

Quote:

See the code in my previous post. That's what it does. You're too late to start said religion, but you can join. For offerings, I accept cash, major credit cards, and cake. Mainly cake.

Erika,

I noticed that your code had comments about not sorting to save time.

I did a bit of testing on this quite a while ago, and discovered that sorting before using @UniqueStringArray will always result in a faster process. And especially if you are going to do both, it's much faster to sort first, then run the unique function. My notes indicate that I found it to be 6 times faster than doing it the other way around.

Just to be sure this would still be true in this case, I tested it again on this example. I increased the number of customer records to over 10,000 in order to make it take longer than 1 second to process. Then, I ran this (minus the line that sorts) slightly modified snippet from your example. It took my system 10-11 seconds. After that, I ran it again with the sort, and it took just 6-8 seconds.

var vRS as Int
var vState as String
var vLoop as Int
var vCnt as Int
var vStateList as String
var vDate as Date
var vStart as Int

vStart = @TimeInSeconds()	// Added by Carl

	vDate = @Date

	// Get list of unique States as a StringArray
	// We don't need them to be in order, so we're
	// not gonna waste time on sorting
	vStateList = ""
	vRS = @XResultSetSearch(@FN, "Customers", 0, 2, "")
	If vRS > -1
	{
		vCnt = @XResultSetTotal(vRS)
		For vLoop = 1 To vCnt
			XResultSetCurrentPosition(vRS, vLoop)
			vState = @XResultSetValue(vRS, "State")
			vStateList = vStateList + vState + ";"
		Next
		XResultSetClose(vRS)
	}
	vStateList = @Repllas(vStateList, ";", "")
	vStateList = @SortStringArray(vStateList, 0)	// Added by Carl
	vStateList = @UniqueStringArray(vStateList)

WriteLn(@TimeInSeconds() - vStart)	// Added by Carl 

So, even if you don't need the string to be sorted, I find it's always better to use it anyway, because it helps the unique process run faster.

That's good tip,Carl. I forgot about that.

In this particular case, you might try timing it with the sort on the XResultSet instead of on the string array. It's likely to sort faster and would still let you get the speed increase from running Unique on a presorted list. You never know until you try it though. That's why optimization is often so non-intuitive.

Hammer wrote on Feb 1^st, 2012 at 2:13pm:


Ahh, good idea, so I tested that too.

I would have thought that it would sort faster with XResultSetSort(vRS, "State:-1") instead of sorting the string array, but the times were identical -- 7 seconds either way.

In CalcAndEmit, use vUniqueItemNum instead of vItemNum.

lksseven wrote on Feb 1^st, 2012 at 10:47pm:



Wedding cake!!!!!

Just curious, does it make any difference time wise using; SEARCH_MODE_AND, SEARCH_SYNTAX_QA, versus, 0,2,?