Jonathan M Davis:
> In any case, if you're looking to avoid GC collection cycles, it sounds like
> std.gc.disable() and std.gc.enable() will help. But remember that that will
> increase the odds that it will have to allocate more memory from the OS,
> which
> isn't cheap either. It's almost ce
No worries, I'm just investigating. I don't need real-time performance
any time soon. :)
I have seen a pluggable .NET system that has to run in real-time. If
that's possible in .net, I'm sure it will be possible in D (if it
isn't already).
Thanks for all your input!
On Sat, Sep 11, 2010 at 5:23
On Friday 10 September 2010 19:40:10 Andrej Mitrovic wrote:
> What about gc.disable() and gc.enable() ? If I'm sure that I won't
> allocate anything within a section of code and I have to guarantee
> realtime performance, then I could disable the gc temporarily.
> Although this is not exactly what
This page might need to be updated soon:
http://www.digitalmars.com/d/2.0/memory.html
It refers to custom allocators, overloading new and delete, and using
scope for stack allocation.
On Sat, Sep 11, 2010 at 4:40 AM, Andrej Mitrovic
wrote:
> What about gc.disable() and gc.enable() ? If I'm sure
What about gc.disable() and gc.enable() ? If I'm sure that I won't
allocate anything within a section of code and I have to guarantee
realtime performance, then I could disable the gc temporarily.
Although this is not exactly what it states in the section on memory
management:
"Call std.gc.disable
On Friday 10 September 2010 17:36:06 Andrej Mitrovic wrote:
> This is why I'm happy to see some people (Leandro in particular) are
> already working on different GC designs for D. :)
>
> So to evade the GC's pauses as much as possible, one would stick with
> using structs or preallocate all needed
This is why I'm happy to see some people (Leandro in particular) are
already working on different GC designs for D. :)
So to evade the GC's pauses as much as possible, one would stick with
using structs or preallocate all needed data before a critical
section? I'll have to get more into that event
On Friday 10 September 2010 09:44:10 bearophile wrote:
> Andrej Mitrovic:
> > So does that mean the GC doesn't make any pauses, unless it requires more
> > memory from the OS?
>
> When you ask memory to the GC, it may perform collections, so it performs
> some computations, even if no new memory g
Andrej Mitrovic:
> So does that mean the GC doesn't make any pauses, unless it requires more
> memory from the OS?
When you ask memory to the GC, it may perform collections, so it performs some
computations, even if no new memory gets asked to the OS.
Bye,
bearophile
Let's see if I got this right. The GC asks for some memory from the OS, and
keeps it in a pool. Then when we have to allocate an array, we take some memory
from the GC pool. And when we no longer need the array, the memory gets put
back into the pool to be reused. So does that mean the GC doesn'
On 09/10/2010 10:17 AM, Jonathan M Davis wrote:
On Friday 10 September 2010 00:50:32 bearophile wrote:
Jonathan M Davis:
Aren't they _always_ on the heap?
void main() {
int[10] a;
int[] b = a[];
}
Bye,
bearophile
Ah, good point. When you have a slice of a static array as opposed
On Friday 10 September 2010 00:50:32 bearophile wrote:
> Jonathan M Davis:
> > Aren't they _always_ on the heap?
>
> void main() {
> int[10] a;
> int[] b = a[];
> }
>
> Bye,
> bearophile
Ah, good point. When you have a slice of a static array as opposed to a dynamic
arra allocated with
Jonathan M Davis:
> Aren't they _always_ on the heap?
void main() {
int[10] a;
int[] b = a[];
}
Bye,
bearophile
On Thursday 09 September 2010 23:23:45 bearophile wrote:
> Jonathan M Davis:
> > Now, dynamic arrays live on the stack, even if their references don't,
>
> Dynamic arrays are generally on the heap.
>
> Bye,
> bearophile
Aren't they _always_ on the heap? Their references are obviously on the stac
Jonathan M Davis:
> Now, dynamic arrays live on the stack, even if their references don't,
Dynamic arrays are generally on the heap.
Bye,
bearophile
On Thursday 09 September 2010 20:54:15 Dr. Smith wrote:
> Jonathan, thank you for the quick response. I made some changes as you
> suggested and got much more speed. For some code that I'd like to convert
> to D, I am exploring the pros and cons of constructing a class library
> (versus a C like f
On Thursday 09 September 2010 20:17:23 Andrej Mitrovic wrote:
> Related: Do stack variables get freed on exit or do they just get marked as
> unused by the GC? Because I'm not seeing any memory increase over time. I
> guess I have to read more about how allocation works. :p
>
> Jonathan M Davis Wr
Jonathan, thank you for the quick response. I made some changes as you
suggested
and got much more speed. For some code that I'd like to convert to D, I am
exploring the pros and cons of constructing a class library (versus a C like
function library). My code here is just part of that exploration
On Thursday 09 September 2010 19:40:47 Dr. Smith wrote:
> The class code below runs terribly slow. Conversely, when converted into a
> function (albeit returning only one value), it runs fast. Any insights
> into this or suggestions to get a function to return multiple types at
> once?
>
> ...li
Related: Do stack variables get freed on exit or do they just get marked as
unused by the GC? Because I'm not seeing any memory increase over time. I guess
I have to read more about how allocation works. :p
Jonathan M Davis Wrote:
_every time_ that you use hit or
> hot in main(), you're callin
On Thursday 09 September 2010 19:40:47 Dr. Smith wrote:
> The class code below runs terribly slow. Conversely, when converted into a
> function (albeit returning only one value), it runs fast. Any insights
> into this or suggestions to get a function to return multiple types at
> once?
>
> ...li
The class code below runs terribly slow. Conversely, when converted into a
function (albeit returning only one value), it runs fast. Any insights into
this or suggestions to get a function to return multiple types at once?
...library code...
module testlib;
import std.stdio, std.string;
class
22 matches
Mail list logo