• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Thought for the day

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Thought for the day

    Performance of .NET's BitVector32 is disappointing and having to declare access to (interfaced) variables in interface classes seems to hit performance too.

    #2
    Wise words, Alexei

    I shall carry them in my heart all day tomorrow.
    Probably.
    Why not?

    Comment


      #3
      Didn't you talk about BitVector class about a year ago Alexei?

      Surely you have moved on since then?

      Comment


        #4
        Originally posted by Dundeegeorge
        I shall carry them in my heart all day tomorrow.
        Probably.
        Me too. It's exciting moments like this that make one's life worth living.

        Comment


          #5
          Originally posted by AtW
          Performance of .NET's BitVector32 is disappointing and having to declare access to (interfaced) variables in interface classes seems to hit performance too.
          I once wrote two programs to manipulate maps and lists. The first used STL, the second MFC. Guess which was fastest? Yup. The STL program was twice as fast as the MS one.

          MS are agressive and well marketed, but often not the best. As an example, COM is widely used, and has helped me earn a living. But IMO it can be fiendishly difficult to maintain, especially for those unskilled in the technology. And the debugging support is awful. It's as if MS are creating a demand for geeks with specialist MS knowledge.

          Comment


            #6
            Perhaps you can be more specific about what is wrong with the BitVector32 class and I'll see if we can fix it for you?

            Comment


              #7
              Nothing is wrong, its just not as fast as doing bitshifts yourself - it sure is annoying to create bitmasks manually but its a LOT faster - with luck compiler will also inline those shifts, something it definately won't do for normal BitVector32 operations that use indexer - function calls are not cheap on x86.

              Now interface really annoyed me by requiring to use accessors for variables (that were declared in interface) - rather annoying since I can't see any good reason for that.

              Comment


                #8
                You mean this?

                public int this[BitVector32.Section section]
                {
                get
                {
                return (int) ((this.data & (section.Mask << (section.Offset & 0x1f))) >> (section.Offset & 0x1f));
                }
                set
                {
                value = value << (section.Offset & 0x1f);
                int num1 = (0xffff & section.Mask) << (section.Offset & 0x1f);
                this.data = (uint) ((this.data & ~num1) | (value & num1));
                }
                }

                Comment


                  #9
                  shoot me

                  Older and ...well, just older!!

                  Comment


                    #10
                    Originally posted by Fungus
                    I once wrote two programs to manipulate maps and lists. The first used STL, the second MFC. Guess which was fastest? Yup. The STL program was twice as fast as the MS one.
                    That's just stupid. They're both template container classes to help you out, neither are meant to be the best possible solution. If you really wanted performance, you should have used your own classes and optimised it to do exactly what you needed. And we don't know that you're comparing like with like here.

                    Frankly I've always thought STL was needlessly over complicated, and that the MFC container classes are much easier to use.

                    It's as if MS are creating a demand for geeks with specialist MS knowledge.
                    Well errr yeah. What's .NET if not a way to generate work for the industry and further their hold on it?
                    Will work inside IR35. Or for food.

                    Comment

                    Working...
                    X