5 ms·

>"I hadn’t optimized for memory use in the first place." It is git, it is made to grow and get into billions of string comparisons. Anyways... C/c++ would hav

>"I hadn’t optimized for memory use in the first place." It is git, it is made to grow and get into billions of string comparisons. Anyways... C/c++ would have probably been a better language for his problem. Simply prealocate as much as needed as a working buffer and eliminate the need to profile libc and patch your interpreter altogether.

Kenji 10y ago
I concur. If the memory allocator causes problems and you use a language with managed memory/a garbage collector, you're doing something wrong.
- Filligree 10y ago
  An aggressive, copying garbage collector would have eliminated this problem from the start. People often argue that GCs have unavoidable overhead, but it's bounded overhead; they defragment your program with every GC cycle.
  - Kenji 10y ago
    GC does have unavoidable overhead, in particular, it makes the execution times of your binary extremely unstable and high-variance. Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach while with manual management, you can get real and high performance.
    - pg314 10y ago
      > it makes the execution times of your binary extremely unstable and high-variance. Not necessarily, it depends on your allocation patterns. The same can be said for using malloc. > Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach Ditto for malloc. > with manual management, you can get real and high performance. Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects. You keep a free list of Point objects that you can recycle. If you need a Point, you first see if there are any in the free list. If so, you pop the first one off the list and reuse it. Otherwise you allocate a new one. When you're done with a Point, you push it on the free list.
      - jstimpfle 10y ago
        >> Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach > Ditto for malloc. malloc != manual management > Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects... But that's not using a GC. It's manual memory management.
        buzzybee 10y ago
        That's aggressively missing the point. If you design the program architecture around manual memory techniques, the runtimes are stable even in a GC. If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable.
        jstimpfle 10y ago
        But my point was simply that you can't defend GC by contrasting to manual management, if you do manual management. > If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable. First, where did I say "use malloc willy-nilly"? Second, do you have experience with that? I haven't much, but I haven't heard your claim before. Of course "willy-nilly" should not be done with real-time constraints. But I have written a substantial algorithmic program (no RT constraints) in that style when I didn't know better, and it was very well performing. (probably glibc's malloc was optimized for my allocation patterns). The main problem I see with that style is that each malloc has memory overhead, and that it leads to unmaintainable code.
        Kenji 10y ago
        Actually, to address realtime constraints... In my job, I work on systems with realtime constraints and even in less critical parts (latency of ~100 microseconds is still acceptable) we had to eliminate all malloc calls. Mostly because malloc on our platform essentially acquires one big lock for memory operations and if some other process has that lock, you get nasty delays or even priority inversions. Allocate a big chunk beforehand, preferrably in the form of ring buffers, and then operate on these if you need precise timing and performance.
    - mgottein 10y ago
      I personally believe one of the biggest reasons for the popularity of managed code is GC. Manual memory management is pretty hard to get right, even the C++ stl offers reference counted pointers as a form of automatic memory management
      - dbaupp 10y ago
        I think that is a rather common belief... "Managed" is exactly referring to automatic memory management meaning the defining feature of the category is literally GC.
        jstimpfle 10y ago
        Wikipedia disagrees. "Managed code is computer program source code that requires and will execute only under the management of a Common Language Runtime virtual machine, typically the .NET Framework, or Mono. The term was coined by Microsoft."
        dbaupp 10y ago
        Huh. By that definition Java isn't managed, which seems to be missing the point and not as nearly useful as a broad category like everyone outside the Microsoft ecosystem uses it. That said, even if "CLR" is sensibly replaced with "CLR, JVM or similar", it does seem like I have the etymology/definition wrong, thanks.
        jstimpfle 10y ago
        Yes, I also think of Java as "managed". But the common idea of "managed" seems to be more than only "garbage collected".
glandium 10y ago
Author here. FWIW, git-cinnabar is written in python because it uses the mercurial code to talk to mercurial servers, and the mercurial code is in python. Well, that was true when it was first released, but recent versions have gained "native" support to talk to mercurial servers (where a helper program written in C does the talking[1]), although the mercurial code is still used to read bundle2[2] data that comes from the mercurial server, even in that case (that is, only bundle1 is supported without using mercurial code). I'm moving more and more things to the helper with the ultimate goal of not having any python code left. 1. https://glandium.org/blog/?p=3648 https://glandium.org/blog/?p=3648 2. https://www.mercurial-scm.org/wiki/BundleFormat2 https://www.mercurial-scm.org/wiki/BundleFormat2

Kenji 10y ago

I concur. If the memory allocator causes problems and you use a language with managed memory/a garbage collector, you're doing something wrong.

Filligree 10y ago
An aggressive, copying garbage collector would have eliminated this problem from the start. People often argue that GCs have unavoidable overhead, but it's bounded overhead; they defragment your program with every GC cycle.
- Kenji 10y ago
  GC does have unavoidable overhead, in particular, it makes the execution times of your binary extremely unstable and high-variance. Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach while with manual management, you can get real and high performance.
  - pg314 10y ago
    > it makes the execution times of your binary extremely unstable and high-variance. Not necessarily, it depends on your allocation patterns. The same can be said for using malloc. > Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach Ditto for malloc. > with manual management, you can get real and high performance. Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects. You keep a free list of Point objects that you can recycle. If you need a Point, you first see if there are any in the free list. If so, you pop the first one off the list and reuse it. Otherwise you allocate a new one. When you're done with a Point, you push it on the free list.
    - jstimpfle 10y ago
      >> Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach > Ditto for malloc. malloc != manual management > Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects... But that's not using a GC. It's manual memory management.
      - buzzybee 10y ago
        That's aggressively missing the point. If you design the program architecture around manual memory techniques, the runtimes are stable even in a GC. If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable.
        jstimpfle 10y ago
        But my point was simply that you can't defend GC by contrasting to manual management, if you do manual management. > If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable. First, where did I say "use malloc willy-nilly"? Second, do you have experience with that? I haven't much, but I haven't heard your claim before. Of course "willy-nilly" should not be done with real-time constraints. But I have written a substantial algorithmic program (no RT constraints) in that style when I didn't know better, and it was very well performing. (probably glibc's malloc was optimized for my allocation patterns). The main problem I see with that style is that each malloc has memory overhead, and that it leads to unmaintainable code.
        Kenji 10y ago
        Actually, to address realtime constraints... In my job, I work on systems with realtime constraints and even in less critical parts (latency of ~100 microseconds is still acceptable) we had to eliminate all malloc calls. Mostly because malloc on our platform essentially acquires one big lock for memory operations and if some other process has that lock, you get nasty delays or even priority inversions. Allocate a big chunk beforehand, preferrably in the form of ring buffers, and then operate on these if you need precise timing and performance.
  - mgottein 10y ago
    I personally believe one of the biggest reasons for the popularity of managed code is GC. Manual memory management is pretty hard to get right, even the C++ stl offers reference counted pointers as a form of automatic memory management
    - dbaupp 10y ago
      I think that is a rather common belief... "Managed" is exactly referring to automatic memory management meaning the defining feature of the category is literally GC.
      - jstimpfle 10y ago
        Wikipedia disagrees. "Managed code is computer program source code that requires and will execute only under the management of a Common Language Runtime virtual machine, typically the .NET Framework, or Mono. The term was coined by Microsoft."
        dbaupp 10y ago
        Huh. By that definition Java isn't managed, which seems to be missing the point and not as nearly useful as a broad category like everyone outside the Microsoft ecosystem uses it. That said, even if "CLR" is sensibly replaced with "CLR, JVM or similar", it does seem like I have the etymology/definition wrong, thanks.
        jstimpfle 10y ago
        Yes, I also think of Java as "managed". But the common idea of "managed" seems to be more than only "garbage collected".

glandium 10y ago

Author here. FWIW, git-cinnabar is written in python because it uses the mercurial code to talk to mercurial servers, and the mercurial code is in python. Well, that was true when it was first released, but recent versions have gained "native" support to talk to mercurial servers (where a helper program written in C does the talking[1]), although the mercurial code is still used to read bundle2[2] data that comes from the mercurial server, even in that case (that is, only bundle1 is supported without using mercurial code). I'm moving more and more things to the helper with the ultimate goal of not having any python code left. 1. https://glandium.org/blog/?p=3648 https://glandium.org/blog/?p=3648 2. https://www.mercurial-scm.org/wiki/BundleFormat2 https://www.mercurial-scm.org/wiki/BundleFormat2