Yes I know it was me who wrote that...

GuyThiebaut

Yes it's self satire... honestly...

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

BobJanova

If we're going for doing it right of course the answer is

if(item.StartsWith("PF_", StringComparison.OrdinalIgnoreCase)) ...

Richard Deeming

Well, if you will insist on writing code that other people can understand and maintain... :rolleyes:

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

BobJanova

I'm sorry I meant

if(1600548864 == (*(int*)&item.ToLower()) << 8) ...

Richard Deeming

That's better! :laugh:

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

OriginalGriff

Nasty! Unsafe code... Please, try to avoid it, especially when it can be done without it so much more clearly:

if (((BitConverter.ToInt32(Encoding.ASCII.GetBytes(item), 0) & 6250335) ^ 6243920) == 0)

Lost User

Clearly a functional language will magically make this far better:

((xum 567 487) (map item (lambda x (find (xor x (and y z)) (encode pi 49)))

The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.

Argonia

if(String.Equals(string1, string2, StringComparison.OrdinalIgnoreCase))
{
...
}

is faster than string.Compare Please kill me now or erase any information about c# from my head.

Microsoft ... the only place where VARIANT_TRUE != true

OriginalGriff

CDP1802 wrote:

((xum 567 487) (map item (lambda x (find (xor x (and y z)) (encode pi 49)))

The language is JavaScript. that of Mordor, which I will not utter here

Man! :omg: Javascript has changed!

Richard Deeming

Are you sure? They both use a virtually identical approach behind the scenes. And since the original code is only comparing the first three characters of the item string, you'd have to use Substring to create a new string before you could call Equals, which would almost certainly be slower.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

OriginalGriff

Yes!

        string string1 = File.ReadAllText(@"D:\\Temp\\MyText.txt");
        string string2 = File.ReadAllText(@"D:\\Temp\\MyText.txt");
        int x = 0;
        Stopwatch sw1 = new Stopwatch();
        sw1.Start();
        for (int i = 0; i < 1000; i++)
            {
            if (String.Equals(string1, string2, StringComparison.OrdinalIgnoreCase))
                {
                x++;
                }
            }
        sw1.Stop();
        Console.WriteLine(x);
        x = 0;
        Stopwatch sw2 = new Stopwatch();
        sw2.Start();
        for (int i = 0; i < 1000; i++)
            {
            if (String.Compare(string1, string2, true) == 0)
                {
                x++;
                }
            }
        sw2.Stop();
        Console.WriteLine(x);
        Console.WriteLine("{0}:{1}", sw1.ElapsedMilliseconds, sw2.ElapsedMilliseconds);

(The file is one of my standard test files: 1.6MB of Ipsum Lorem paragraphs) Results:

1000
1000
1716:4071

Richard Deeming

That's strange - on my computer, with a similar sized text file, Compare(string, string, bool) is consistently faster:

1000
1000
13997:3431

I'm running .NET 4.5.1 on Win7 x64. Also, string.Compare(s1, s2, true) isn't the same as string.Equals(s1, s2, StringComparison.OrdinalIgnoreCase); it's equivalent to StringComparison.CurrentCultureIgnoreCase. Try using string.Compare(s1, s2, StringComparison.OrdinalIgnoreCase) instead.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

OriginalGriff

Interesting: I'm also Win7/64, but .NET 4.0 rather than 4.5. Adding OrdinalIgnoreCase:

        string string1 = File.ReadAllText(@"D:\\Temp\\MyText.txt");
        string string2 = File.ReadAllText(@"D:\\Temp\\MyText.txt");
        int x = 0;
        Stopwatch sw1 = new Stopwatch();
        sw1.Start();
        for (int i = 0; i < 1000; i++)
            {
            if (String.Equals(string1, string2, StringComparison.OrdinalIgnoreCase))
                {
                x++;
                }
            }
        sw1.Stop();
        Console.WriteLine(x);
        x = 0;
        Stopwatch sw2 = new Stopwatch();
        sw2.Start();
        for (int i = 0; i < 1000; i++)
            {
            if (String.Compare(string1, string2, true) == 0)
                {
                x++;
                }
            }
        sw2.Stop();
        Console.WriteLine(x);
        x = 0;
        Stopwatch sw3 = new Stopwatch();
        sw3.Start();
        for (int i = 0; i < 1000; i++)
            {
            if (String.Compare(string1, string2, StringComparison.OrdinalIgnoreCase) == 0)
                {
                x++;
                }
            }
        sw3.Stop();
        Console.WriteLine(x);
        Console.WriteLine("{0}:{1}:{2}", sw1.ElapsedMilliseconds, sw2.ElapsedMilliseconds,sw3.ElapsedMilliseconds);

gives results similar to yours:

1000
1000
1000
1694:4087:1684

I'm surprised there is such a difference in performance between our machines: mine isn't anywhere near state of the art - more state of the ark! :laugh:

Argonia

Ah, the mysteries of M$. Our life will be so empty and boring without them. The same code (Sorry Griff i should pay you author rights) the result was

1000
1000
1000
4359:2216:4383

.Net 4.5 Win 7/64

Microsoft ... the only place where VARIANT_TRUE != true

Richard Deeming

It must be .NET 4.5 - my machine's an early Vista-era dual-core.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

OriginalGriff

Out of interest, are you building for "Any CPU", "x64" or "x32"? Mine is built "x32" because that's what the app I shoved the code in is built for.

Argonia

The results i pasted was with "Any CPU" x64

1000
1000
1000
5363:2199:5338

x86

1000
1000
1000
4530:2305:4519

Visual studio Premium 2012 version 11 with Update 3, Win7/64, .NET 4.5.50709 to be exact Anyway i don't see how he gets ~14 seconds for String.Equals P.S i should say i have problems with my hard at work. I am waiting for it to die. This also can affect the pasted data. I wonder what the results will be with reading from SSD Note to myself : seconds comes after milliseconds not minutes. Stupid

Microsoft ... the only place where VARIANT_TRUE != true

Richard Deeming

It's milliseconds, so it was just under 14 seconds, not minutes! ;P I'm running the code in LinqPad[^], and I've tried both with and without optimisations enabled, but it doesn't make a huge difference.

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

Argonia

Yeah i know its in milliseconds but my upper processor forgot that after miliseconds seconds are next not minutes :D I am running it in debug mode with no optimisations.

Microsoft ... the only place where VARIANT_TRUE != true

Jorgen Andersson

You'll have to redo the test using the same textfile. I believe that's where most of the difference lies.

Politicians are always realistically manoeuvering for the next election. They are obsolete as fundamental problem-solvers. Buckminster Fuller