Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. .NET (Core and Framework)
  4. Where are Value types going ?

Where are Value types going ?

Scheduled Pinned Locked Moved .NET (Core and Framework)
questioncsharpcomdata-structuresperformance
9 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    Sandeep Akhare
    wrote on last edited by
    #1

    Hi all, I don't know how many times this question has been asked in any .NET Forum, but still i have certain doubts regarding value types storage. In almost every book (I read)it is written that value types are going to be stored in Stack. But in some articles i read "value types are stored where they are declared" is that true ? If it is true then valu types declared in class will get stored in Heap. And GC will deallocate them. So what about the performance whenever we are using value types in class Boxing is going to happen ? What happening inside ? Please i require more information regarding these as i couldn't find it.

    Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

    modified on Wednesday, August 6, 2008 2:52 AM

    M 1 Reply Last reply
    0
    • S Sandeep Akhare

      Hi all, I don't know how many times this question has been asked in any .NET Forum, but still i have certain doubts regarding value types storage. In almost every book (I read)it is written that value types are going to be stored in Stack. But in some articles i read "value types are stored where they are declared" is that true ? If it is true then valu types declared in class will get stored in Heap. And GC will deallocate them. So what about the performance whenever we are using value types in class Boxing is going to happen ? What happening inside ? Please i require more information regarding these as i couldn't find it.

      Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

      modified on Wednesday, August 6, 2008 2:52 AM

      M Offline
      M Offline
      Mark Salsbery
      wrote on last edited by
      #2

      Sandeep Akhare wrote:

      If it is true then valu types declared in class will get stored in Heap.

      Only if the object of the class they are members of is allocated on the managed heap. What if they are members of a value class?

      Sandeep Akhare wrote:

      And GC will deallocate them.

      The GC only manages objects allocated on the managed heap.

      Sandeep Akhare wrote:

      So what about the performance whenever we are using value types in class

      Value types are passed by value - that means a copy has to be made every time a value type object is passed. That's going to be slower than passing a reference I would guess. If value types are members of a ref class then there's no difference - the ref class object holds the value type objects. Mark

      Mark Salsbery Microsoft MVP - Visual C++ :java:

      S 1 Reply Last reply
      0
      • M Mark Salsbery

        Sandeep Akhare wrote:

        If it is true then valu types declared in class will get stored in Heap.

        Only if the object of the class they are members of is allocated on the managed heap. What if they are members of a value class?

        Sandeep Akhare wrote:

        And GC will deallocate them.

        The GC only manages objects allocated on the managed heap.

        Sandeep Akhare wrote:

        So what about the performance whenever we are using value types in class

        Value types are passed by value - that means a copy has to be made every time a value type object is passed. That's going to be slower than passing a reference I would guess. If value types are members of a ref class then there's no difference - the ref class object holds the value type objects. Mark

        Mark Salsbery Microsoft MVP - Visual C++ :java:

        S Offline
        S Offline
        Sandeep Akhare
        wrote on last edited by
        #3

        Thanks Mark, Seems intresting :confused: I don't see any good reason to use value types in the class ? As value types are going to be over head (as GC will Deallocate them) We are not having the benefit of value types when used in Class Any way can you give any article link ?

        Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

        M 1 Reply Last reply
        0
        • S Sandeep Akhare

          Thanks Mark, Seems intresting :confused: I don't see any good reason to use value types in the class ? As value types are going to be over head (as GC will Deallocate them) We are not having the benefit of value types when used in Class Any way can you give any article link ?

          Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

          M Offline
          M Offline
          Mark Salsbery
          wrote on last edited by
          #4

          Sandeep Akhare wrote:

          I don't see any good reason to use value types in the class ? As value types are going to be over head (as GC will Deallocate them)

          A value type as a member of a class is more efficient than a reference type. A value type just takes up space, which will just be part of the space new/gcnew allocates for the object. Reference types need to be allocated and collected separately, adding more overhead.

          Sandeep Akhare wrote:

          Any way can you give any article link ?

          Common Type System Overview[^]

          Mark Salsbery Microsoft MVP - Visual C++ :java:

          S 1 Reply Last reply
          0
          • M Mark Salsbery

            Sandeep Akhare wrote:

            I don't see any good reason to use value types in the class ? As value types are going to be over head (as GC will Deallocate them)

            A value type as a member of a class is more efficient than a reference type. A value type just takes up space, which will just be part of the space new/gcnew allocates for the object. Reference types need to be allocated and collected separately, adding more overhead.

            Sandeep Akhare wrote:

            Any way can you give any article link ?

            Common Type System Overview[^]

            Mark Salsbery Microsoft MVP - Visual C++ :java:

            S Offline
            S Offline
            Sandeep Akhare
            wrote on last edited by
            #5

            Thanks Mark

            Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

            M 1 Reply Last reply
            0
            • S Sandeep Akhare

              Thanks Mark

              Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

              M Offline
              M Offline
              Mark Salsbery
              wrote on last edited by
              #6

              Hopefully you found what you were looking for :) I don't like my last post - it seems irrelevant. The most important thing IMO is how objects are passed around. By reference means just a reference to an object is passed, so any changes to the object effect everywhere a reference is held. Value types are passed by value, so there's always a new unique copy passed. That can be important to know. Cheers, Mark

              Mark Salsbery Microsoft MVP - Visual C++ :java:

              S 1 Reply Last reply
              0
              • M Mark Salsbery

                Hopefully you found what you were looking for :) I don't like my last post - it seems irrelevant. The most important thing IMO is how objects are passed around. By reference means just a reference to an object is passed, so any changes to the object effect everywhere a reference is held. Value types are passed by value, so there's always a new unique copy passed. That can be important to know. Cheers, Mark

                Mark Salsbery Microsoft MVP - Visual C++ :java:

                S Offline
                S Offline
                Sandeep Akhare
                wrote on last edited by
                #7

                Hey Mark, I am aware of these concepts, My real concern was we use value types in the code because those are light weight (as GC wont come into picture and will get diallocated automatically from Stack when their life span is over). But when we use value types in class we lost these advantages as GC will have to remove them and will remain in memory even though their life span is over. I hope, i was able to explain this properly ;) Its really very nice to see that MVP like you is looking back and sees what should and what shouldn't have posted Thanks Mark keep it up :)

                Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

                M 1 Reply Last reply
                0
                • S Sandeep Akhare

                  Hey Mark, I am aware of these concepts, My real concern was we use value types in the code because those are light weight (as GC wont come into picture and will get diallocated automatically from Stack when their life span is over). But when we use value types in class we lost these advantages as GC will have to remove them and will remain in memory even though their life span is over. I hope, i was able to explain this properly ;) Its really very nice to see that MVP like you is looking back and sees what should and what shouldn't have posted Thanks Mark keep it up :)

                  Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

                  M Offline
                  M Offline
                  Mark Salsbery
                  wrote on last edited by
                  #8

                  Sandeep Akhare wrote:

                  But when we use value types in class we lost these advantages as GC will have to remove them and will remain in memory even though their life span is over.

                  I see what you mean, but there's really not a way around it in a managed/garbage-collected environment. C++/CLI (and C# maybe a little) gives you more flexibility in deterministic finalization if it's really an issue. There can also be a benefit to forcing a garbage collection at certain points in an app's lifetime. It just depends on the situation - It's definitely something to think about in performance applications. Cheers! Mark

                  Mark Salsbery Microsoft MVP - Visual C++ :java:

                  S 1 Reply Last reply
                  0
                  • M Mark Salsbery

                    Sandeep Akhare wrote:

                    But when we use value types in class we lost these advantages as GC will have to remove them and will remain in memory even though their life span is over.

                    I see what you mean, but there's really not a way around it in a managed/garbage-collected environment. C++/CLI (and C# maybe a little) gives you more flexibility in deterministic finalization if it's really an issue. There can also be a benefit to forcing a garbage collection at certain points in an app's lifetime. It just depends on the situation - It's definitely something to think about in performance applications. Cheers! Mark

                    Mark Salsbery Microsoft MVP - Visual C++ :java:

                    S Offline
                    S Offline
                    Sandeep Akhare
                    wrote on last edited by
                    #9

                    Mark Salsbery wrote:

                    see what you mean, but there's really not a way around it in a managed/garbage-collected environment.

                    Yes you are right, Actually i had issue with this one only

                    Mark Salsbery wrote:

                    C++/CLI (and C# maybe a little) gives you more flexibility in deterministic finalization if it's really an issue.

                    In C#, we will ovveride the Finalization if object is using some sysytem resources and GC can't realase them

                    Mark Salsbery wrote:

                    There can also be a benefit to forcing a garbage collection at certain points in an app's lifetime.

                    This is what i read in many books " GC is slef tuning don't mess with it " Its good to call GC if you know best time to call (End of game application .. etc )

                    Mark Salsbery wrote:

                    It just depends on the situation - It's definitely something to think about in performance applications.

                    Very true,

                    Thanks and Regards Sandeep If If you look at what you do not have in life, you don't have anything, If you look at what you have in life, you have everything... " Check My Blog

                    1 Reply Last reply
                    0
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • World
                    • Users
                    • Groups