Hi Chris
Chris wrote:Good point, in order to make it thread safe, better use a new object each time. You could use BEGIN LOCK...END to lock the single one while it is being used by one thread, but that would not allow it to work in parallel, so no point.
Yupp, deleting the few lines felt bad from perf point, but deleting "Global" also feels "right".
But the class can be made much more lightweight, for example there's no need to assign a cCR, cLF etc every time, those can be made (external) DEFINEs, or STATIC members of the class, so they get initialized only once. Even better, you can make them a CONST, so they are guaranteed to be initialized only once and not be modified in the class code. Also for getting literal chars, you can use the syntax cChar := c'r' for CR(13), c'n' for LF, c' 'for space etc. So you can change the code to:
PRIVATE CONST cLF := c'n' AS Char
this will improve performance, because the Chr() function is quite slow, as it has to do ansi<->unicode conversions that are not needed in this case.
Had already reached same conclusion - that was how I found the Doc error reported yesterday (already fixed by Robert). Current code is, although I am not fully clear if the _Chr mentioned in the docs coupled with the defines might be better or at least more readable.
Code: Select all
Define Asc_A_Low := 097 && Asc_A + 32
Define Asc_Z_Low := 122 && Asc_Z + 32
CLASS GetWordHandler
/// Single
/// todo: Measure Predicate als Parameter
/// todo: Measure Predicate als local Func
/// lMany:
/// todo: Measure ReversOrder/Stack Exit if smaller
/// todo: Measure Guard against Containskey
/// todo: Check Guard about AscW-logic against Containskey
*-- gets faster runtime if declared immutable? Not really...
private const _cSpace := c' ' as Char && _Chr(ASC_BLANK) Chr(032)[0]
private const _c_CRet := c'r' as Char && _Chr(ASC_CR) Chr(013)[0]
private const _c_LinF := c'n' as Char && _Chr(ASC_LF) Chr(010)[0]
private const _c__Tab := c't' as Char && _Chr(ASC_Tab) Chr(009)[0]
private const _c_Up_A := c'A' as Char && _Chr(ASC_A) Chr(065)[0]
private const _c_Up_Z := c'Z' as Char && _Chr(ASC_Z) Chr(090)[0]
private const _c_Lw_a := c'a' as Char && _Chr(ASC_A_Low) Chr(097)[0]
private const _c_Lw_z := c'z' as Char && _Chr(ASC_Z_Low) Chr(122)[0]
In the already defined ASC-xxx perhaps specifying upper and lower begin/end letters might be clearer.
In general regarding performance, when the speed in X# is comparable to that of VFP, I would leave it as it is, no need to spend a lot of time to squeeze just a couple more %, better use the time instead to implement more functions. Unless someone complains that a function is not fast enough, in which case we can go back to it
Yes and No - I realize that "function speed" at the moment does not need more polish - but my education in things Dotnet AND characteristics of xSharp does.
And it already brought at least one speedup: the answer to the old C joke
What is the fastest C data structure
holds true for C# / xSharp as well:
Code: Select all
internal method isVfpWhiteSwitchChar(tc2Check as Char) as Boolean
/// direct switch checking against constants
/// ToDo: flagged version, flags set on SetDict? Measure setup time!
switch tc2Check
case _cSpace
case _c_LinF
case _c__Tab
return .t.
otherwise
return .f.
end switch
The idea of "typical ranges" fed also proved very benefical eliminating the need to call dict:ContainsKey, Most of the Chars fall into Ranges a..z, A..Z and are typically not part of delimiter, allowing to code a guard. I read the source of AscW
Code: Select all
FUNCTION AscW(c AS STRING) AS DWORD
LOCAL ascValue := 0 AS DWORD
LOCAL chValue AS CHAR
IF ( !String.IsNullOrEmpty(c) )
chValue := c[0]
ascValue := (DWORD) chValue
ENDIF
RETURN ascValue
and I already have a Char known to be != Null, so I could safely just
on the notion that lower 127 values of unicode should be identical to ASCII, which could result in efficient code
Code: Select all
internal method isViaDictGuardedAscW(tc2Check as Char) as Boolean
/// Asc/AscW method signature is (String), is taking the relevant cast from AscW enough for Chars<Chr(128)?
/// as Chr(122)=="z" normal ascii letters included, which are main part in US and Europe
/// as Callup crashes earlier (also in vfp) on tcString is Null, even shortened version of Nullcheck not necessary?
/// IIF ( Object.ReferenceEquals(tc2Check, Null), 0, (DWORD) tc2Check )
local lnDword := (DWord) tc2Check as DWord
if (Asc_A_Low<=lnDword .and. lnDWord<=Asc_Z_Low) && lower letters first, as ocurring more often
return .f.
elseif (Asc_A<=lnDword .and. lnDWord<=Asc_Z)
return .f.
else
switch lnDword
case Asc_Blank
return .t.
case Asc_LF
return .t.
case Asc_Tab
return .t.
otherwise
return Self:hcCmp:ContainsKey(tc2Check)
end switch
endif
but here I hesitate at the moment. Dedicated returns inside switch here on purpose, as they might be combined with flags set on Self:SetDict(). When you asked on other thread
But why are you thinking to use those, why are they better in your case than normal procedural code?
I wanted to "plug together" such filters depending on tcDelimiter via small filter functions, which in normal procedural code either need 1 long method guarded with class member flags or a permutation-based # of methods for all combinations. Will probably resolve to flags. Funny: in Vfp slinging those filters together into 1 boolean statement would be faster - I assumed in xSharp to see identical performance between short-circuting Boolean statement and more readable if/elseif/else - not so. If was faster!
regards
thomas
