operator == is more performant than
Compare if you're only testing for equality, because that's all it does. From the source:
== is in NameTypes.h:
FORCEINLINE bool operator==(const FName& Other) const
return GetComparisonIndexFast() == Other.GetComparisonIndexFast() && GetNumber() == Other.GetNumber();
static_assert(sizeof(CompositeComparisonValue) == sizeof(*this), "ComparisonValue does not cover the entire FName state");
return CompositeComparisonValue == Other.CompositeComparisonValue;
Compare is here:
int32 FName::Compare( const FName& Other ) const
// Names match, check whether numbers match.
if( GetComparisonIndexFast() == Other.GetComparisonIndexFast() )
return GetNumber() - Other.GetNumber();
// Names don't match. This means we don't even need to check numbers.
TNameEntryArray& Names = GetNames();
const FNameEntry* const ThisEntry = GetComparisonNameEntry();
const FNameEntry* const OtherEntry = Other.GetComparisonNameEntry();
// Ansi/Wide mismatch, convert to wide
if( ThisEntry->IsWide() != OtherEntry->IsWide() )
return FCStringWide::Stricmp( ThisEntry->IsWide() ? ThisEntry->GetWideName() : StringCast<WIDECHAR>(ThisEntry->GetAnsiName()).Get(),
OtherEntry->IsWide() ? OtherEntry->GetWideName() : StringCast<WIDECHAR>(OtherEntry->GetAnsiName()).Get() );
// Both are wide.
else if( ThisEntry->IsWide() )
return FCStringWide::Stricmp( ThisEntry->GetWideName(), OtherEntry->GetWideName() );
// Both are ansi.
return FCStringAnsi::Stricmp( ThisEntry->GetAnsiName(), OtherEntry->GetAnsiName() );
Note that both do precisely the same thing to test for equality, but compare goes on to test for ordering if they aren't equal, whereas == does not. So in the case of equality their performance is identical, but == outperforms compare when the strings aren't equal because it does no further processing.
Use compare when you need ordering, == when you only need equality.
As for your choice of construction, it does not matter.
== FName(TEXT(...)) is identical to
== TEXT(...) (same with compare), the latter case simply implicitly calls the appropriate
FName constructor according to the usual C++ conversion rules, given the lack of specific == and Compare overloads. I would go with
== TEXT(...) simply because it is less verbose, but also because you'll benefit from any specific potentially-optimized overloads they may choose to add in the future.
Feb 12 '17 at 06:41 PM