I can't seem to be able to use `--profile` with vibe:
```shell
dub init -t vibe.d
dub build --build=profile
../../.dub/packages/vibe-core/2.7.3/vibe-core/source/vibe/internal/async.d-mixin-119(142,3):
Warning: statement is not reachable
../../.dub/packages/vibe-core/2.7.3/vibe-core/source/vibe/
On Sunday, 22 October 2023 at 13:16:11 UTC, Imperatorn wrote:
On Sunday, 22 October 2023 at 13:13:55 UTC, Imperatorn wrote:
I would just like to share some knowledge about profiling an
exe using Visual Studio, since many might already have that
installed.
[...]
On Sunday, 22 October 2023
On Sunday, 22 October 2023 at 13:13:55 UTC, Imperatorn wrote:
I would just like to share some knowledge about profiling an
exe using Visual Studio, since many might already have that
installed.
[...]
On Sunday, 22 October 2023 at 13:13:55 UTC, Imperatorn wrote:
Just a clarification.
"
I would just like to share some knowledge about profiling an exe
using Visual Studio, since many might already have that installed.
After you have built your executable with symbols, open VS and
choose "Continue without code".
Then just choose open Project/Solution (Ctrl+Shift+O)
Thanks in advance for any assistance.
As the subject line states I'm just now trying to learn
profiling. I have a very small program with 1/2 dozen functions
and would like to see where the cpu is spending the most time.
I've tried both of these lines with identical results:
**l
On 2022-05-29 23:00, Ali Çehreli wrote:
On 5/29/22 13:53, Christian Köstlin wrote:
> According to
>
https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/
> its bad to catch Errors ...
Correct in the sense that the program should not continue after catching
Error.
On 2022-05-29 23:08, Ali Çehreli wrote:
On 5/29/22 13:47, Christian Köstlin wrote:
> Our discussion with using TLS for the
> collectors proposed to not need any lock on the add method for
> collector, because its thread local and with that thread safe?
It would be great that way but then the
On 5/29/22 13:47, Christian Köstlin wrote:
> Our discussion with using TLS for the
> collectors proposed to not need any lock on the add method for
> collector, because its thread local and with that thread safe?
It would be great that way but then the client changed the requirements
on us:
O
On 5/29/22 13:53, Christian Köstlin wrote:
> According to
>
https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/
> its bad to catch Errors ...
Correct in the sense that the program should not continue after catching
Error.
> so dowork should catch only Exception?
On 2022-05-29 20:52, Ali Çehreli wrote:
On 5/27/22 06:55, Christian Köstlin wrote:
> I wonder how I can synchronize the "dumping" and the
> collection of the threads. Would be cool to have an efficient lockless
> implementation of appender ...
That turned out to be nontrivial.
The following
On 2022-05-29 20:52, Ali Çehreli wrote:
On 5/27/22 06:55, Christian Köstlin wrote:
> I wonder how I can synchronize the "dumping" and the
> collection of the threads. Would be cool to have an efficient lockless
> implementation of appender ...
That turned out to be nontrivial.
The following
On 5/27/22 06:55, Christian Köstlin wrote:
> I wonder how I can synchronize the "dumping" and the
> collection of the threads. Would be cool to have an efficient lockless
> implementation of appender ...
That turned out to be nontrivial.
The following is a draft I played with. Collector collect
On 2022-05-26 22:19, Ali Çehreli wrote:
On 5/26/22 12:54, Christian Köstlin wrote:
> I want to be able to dump
> tracings even while the program is still running. Then I would have to
> collect the tls data of all still running threads.
I am not sure without testing but I am under the impres
On 5/26/22 12:54, Christian Köstlin wrote:
> I want to be able to dump
> tracings even while the program is still running. Then I would have to
> collect the tls data of all still running threads.
I am not sure without testing but I am under the impression that mutexes
can be very slow especial
On 2022-05-25 23:56, Ali Çehreli wrote:
On 5/25/22 14:35, Christian Köstlin wrote:
> 1. I went for a singleton for storing tracing/logging information that
> needs to be initialized manually. Is __gshared the right way to do that?
I think this is where thread-local storage comes in handy. As
On 2022-05-26 01:05, frame wrote:
On Wednesday, 25 May 2022 at 21:35:07 UTC, Christian Köstlin wrote:
Is there also a way to get the "real"
threadid?
I'm using that functions inside threads:
core.sys.windows.winbase.GetCurrentThreadId on Windows
core.sys.posix.pthread.pthread_self on Unix (im
On Wednesday, 25 May 2022 at 21:35:07 UTC, Christian Köstlin
wrote:
Is there also a way to get the "real"
threadid?
I'm using that functions inside threads:
core.sys.windows.winbase.GetCurrentThreadId on Windows
core.sys.posix.pthread.pthread_self on Unix (implied pthreads are
used)
On 5/25/22 14:35, Christian Köstlin wrote:
> 1. I went for a singleton for storing tracing/logging information that
> needs to be initialized manually. Is __gshared the right way to do that?
I think this is where thread-local storage comes in handy. As the D
runtime does for dmd's -profile comm
I experimented with application level tracing/profiling of d
applications similar to what is described in
https://dlang.org/blog/2020/03/13/tracing-d-applications/ as the
"writef-based approach". Only difference is, that I am emitting json
(https://docs.google.com/document/d/1Cv
On Tuesday, 24 August 2021 at 10:33:07 UTC, JG wrote:
The reason for the crash boils down to the fact that this fails:
foreach(k; sort!"a > b"(funcs.keys)) assert(k in funcs);
funcs is of type ubyte[4][float]
Is this a compiler bug?
That assert will fail if there are NaN keys in the AA. This
On Tuesday, 24 August 2021 at 09:45:31 UTC, JG wrote:
On Tuesday, 24 August 2021 at 09:42:29 UTC, JG wrote:
On Tuesday, 24 August 2021 at 09:36:06 UTC, JG wrote:
[...]
In case anyone is interested it seems that it was forked to
here:
https://github.com/joakim-brannstrom/profdump
Perhaps t
On Tuesday, 24 August 2021 at 09:42:29 UTC, JG wrote:
On Tuesday, 24 August 2021 at 09:36:06 UTC, JG wrote:
On Wednesday, 10 February 2021 at 23:42:31 UTC, mw wrote:
[...]
I tried to do this, but I am not sure how to install profdump.
What I did is cloned the repository using git.
Tried to bu
On Tuesday, 24 August 2021 at 09:36:06 UTC, JG wrote:
On Wednesday, 10 February 2021 at 23:42:31 UTC, mw wrote:
[...]
I tried to do this, but I am not sure how to install profdump.
What I did is cloned the repository using git.
Tried to build it using dub but got an error as described here:
[
On Wednesday, 10 February 2021 at 23:42:31 UTC, mw wrote:
On Wednesday, 10 February 2021 at 11:52:51 UTC, JG wrote:
As a follow up question I would like to know what tool people
use to profile d programs?
I use this one:
https://code.dlang.org/packages/profdump
e.g.
```
dub build --build=
On 2/9/21 12:45 AM, JG wrote:
I was trying to profile a d program. So I ran: dub build
--build=profile. I then ran the program and it produced trace.log and
trace.def. I then ran d-profile-viewer and got the following error:
std.conv.ConvException@/home/jg/dlang/ldc-1.24.0/bin/../import/std/co
On Wednesday, 10 February 2021 at 23:42:31 UTC, mw wrote:
On Wednesday, 10 February 2021 at 11:52:51 UTC, JG wrote:
As a follow up question I would like to know what tool people
use to profile d programs?
I use this one:
https://code.dlang.org/packages/profdump
e.g.
```
dub build --build=
On Wednesday, 10 February 2021 at 11:52:51 UTC, JG wrote:
As a follow up question I would like to know what tool people
use to profile d programs?
I use this one:
https://code.dlang.org/packages/profdump
e.g.
```
dub build --build=debug --build=profile
# run your program to generate trace
On Wednesday, 10 February 2021 at 13:31:09 UTC, Guillaume Piolat
wrote:
On Wednesday, 10 February 2021 at 11:52:51 UTC, JG wrote:
[...]
Here is what I use for sampling profiler:
(On Windows)
Build with LDC, x86_64, with dub -b release-debug in order to
have debug info.
Run your program int
On Wednesday, 10 February 2021 at 11:52:51 UTC, JG wrote:
Thanks for the suggestions. However, I would prefer not to
spend time trying to debug d-profile-viewer at the moment.
As a follow up question I would like to know what tool people
use to profile d programs?
Here is what I use for sa
On 2/10/21 2:52 PM, JG wrote:
On Tuesday, 9 February 2021 at 18:33:16 UTC, drug wrote:
On Tuesday, 9 February 2021 at 07:45:13 UTC, JG wrote:
I was trying to profile a d program. So I ran: dub build
--build=profile. I then ran the program and it produced trace.log and
trace.def. I then ran d-p
On Tuesday, 9 February 2021 at 18:33:16 UTC, drug wrote:
On Tuesday, 9 February 2021 at 07:45:13 UTC, JG wrote:
I was trying to profile a d program. So I ran: dub build
--build=profile. I then ran the program and it produced
trace.log and trace.def. I then ran d-profile-viewer and got
the foll
On Tuesday, 9 February 2021 at 07:45:13 UTC, JG wrote:
I was trying to profile a d program. So I ran: dub build
--build=profile. I then ran the program and it produced
trace.log and trace.def. I then ran d-profile-viewer and got
the following error:
std.conv.ConvException@/home/jg/dlang/ldc-1
int.
Oh wait a bit. The stack trace shows calling some function of
'app.d' - that's presumably your program.
I wonder why it's being called - aren't you supposed to be
viewing the profiling results instead of profiling? I'm not sure
what's happening.
On Tuesday, 9 February 2021 at 07:45:13 UTC, JG wrote:
Is d-profile-viewer no longer working? Or did I do something
wrong?
You may have or may not have done it wrong, but in any case this
is a bug. If you do something wrong, the program should tell you
what you did wrong, instead of telling y
I was trying to profile a d program. So I ran: dub build
--build=profile. I then ran the program and it produced trace.log
and trace.def. I then ran d-profile-viewer and got the following
error:
std.conv.ConvException@/home/jg/dlang/ldc-1.24.0/bin/../import/std/conv.d(2382):
Unexpected '-' wh
On Wednesday, 4 December 2019 at 22:51:45 UTC, Steven
Schveighoffer wrote:
I localized that the leak was actually being caused by
websockets. I want to write down my experience because I did some
weird stuff which seems to be working but I want to learn how it
actually make sense and works.
64-bit land because the chances of accidental
pointers is infinitesimal.
Is there any way to manipulate profile-gc flag on run time? Like I will
start my program without it somehow and after the my program initializes
I will turn it on.
I'm not familiar much with the gc profiling fea
On Wednesday, 4 December 2019 at 15:38:36 UTC, Steven
Schveighoffer wrote:
On 12/4/19 3:10 AM, Erdem wrote:
I am used to have cool tools like valgrid massif to visualize
the memory usage from C++ but in D it seems I am blind folded
looking for the problem.
Until now I tried:
--vgc option whi
On 12/4/19 3:10 AM, Erdem wrote:
I am used to have cool tools like valgrid massif to visualize the memory
usage from C++ but in D it seems I am blind folded looking for the problem.
Until now I tried:
--vgc option which show million things which makes it not useful
--build=profile-gc
which see
I am used to have cool tools like valgrid massif to visualize the
memory usage from C++ but in D it seems I am blind folded looking
for the problem.
Until now I tried:
--vgc option which show million things which makes it not useful
--build=profile-gc
which seems to slow down my program like *
On Sunday, 21 April 2019 at 16:20:51 UTC, WebFreak001 wrote:
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing
some dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this` calls and som
On Sunday, 12 May 2019 at 17:24:24 UTC, Johan Engelen wrote:
Excellent.
I think dub -v will output the exact commands that dub is
executing.
Looks like some parts are not compiled with the compile flag,
and some other parts are?
Got it!
-v displays only one ldc2 execution with -fprofile-i
-fprofile-instr-generate
(indirect calls to such functions may be recorded); the std lib
is not compiled with profiling instrumentation, and so you
shouldn't see any internal instrumentation of it. Unless those
functions are instantiated in your object file (e.g. templates or
explicitly in
On Saturday, 11 May 2019 at 11:38:17 UTC, Denis Feklushkin wrote:
Maybe DUB caches binaries and linker links previous
non-instrumented object files?
I tried "dub clean" and "dub clean-caches" but maybe it is need
remove someting else?
Checked with "dub -f" and nothing changed.
On Saturday, 11 May 2019 at 11:34:35 UTC, Denis Feklushkin wrote:
Tried it, and xray also does not returns any info about my own
functions...
Maybe DUB caches binaries and linker links previous
non-instrumented object files?
I tried "dub clean" and "dub clean-caches" but maybe it is need
rem
On Saturday, 11 May 2019 at 09:12:24 UTC, Johan Engelen wrote:
Those calls are to templated functions I presume?
No
instantiated in your program and hence instrumented)
Also I changed flags to "dflags-ldc":
["-fprofile-instr-generate", "-O0"] - second flag disables
optimisation (I assumed
On Saturday, 11 May 2019 at 06:59:52 UTC, Denis Feklushkin wrote:
On Saturday, 11 May 2019 at 05:46:29 UTC, Denis Feklushkin
wrote:
All another calls is made inside of this lambda - maybe
lambdas is not traced by profiler?
Tried to remove lambda with same result.
Command:
llvm-profdata sho
On Saturday, 11 May 2019 at 05:46:29 UTC, Denis Feklushkin wrote:
All another calls is made inside of this lambda - maybe lambdas
is not traced by profiler?
Tried to remove lambda with same result.
Command:
llvm-profdata show -all-functions -topn=10 default.profdata
returns huge amount
On Friday, 10 May 2019 at 18:09:28 UTC, Johan Engelen wrote:
You only need `-fprofile-instr-generate` for generating
default.profraw.
Yep, it is because I also tried to use uftrace and xray
contains only calls to external libraries
That's impossible, because those are exactly _not_ profi
On Friday, 10 May 2019 at 14:00:30 UTC, Denis Feklushkin wrote:
Build with dub some package. Profiling are enabled by dub.json:
"dflags-ldc": ["-fprofile-instr-generate",
"-finstrument-functions", "-cov"],
Resulting default.profraw (and generated d
Build with dub some package. Profiling are enabled by dub.json:
"dflags-ldc": ["-fprofile-instr-generate",
"-finstrument-functions", "-cov"],
Resulting default.profraw (and generated default.profdata)
contains only calls to external libraries, but not my internal
functions calls.
Why?
ior. Is there any way to check why it isn't profiling
properly?
OS: Linux, DMD 2.085.1 (also reproducible by someone else)
Project: https://github.com/Pure-D/serve-d (run via code-d in
vscode)
On Monday, 29 October 2018 at 10:14:23 UTC, Dukc wrote:
When I run the program, where is the performance profile file
supposed to appear? I can find nothing new in the
program/project root directory.
The same thing happens when I try to get a coverage report: No
file appears.
your profiler.
How? That's the question. If the program is compiled with a
profiling switch, isn't the performance profile supposed to
appear on program directry after it finishes, when running it
just like normal?
On Monday, 29 October 2018 at 10:14:23 UTC, Dukc wrote:
I'm trying to profile my program, built like:
dub build --build=profile
When I run the program, where is the performance profile file
supposed to appear? I can find nothing new in the
program/project root directory. This happens regardle
I'm trying to profile my program, built like:
dub build --build=profile
When I run the program, where is the performance profile file
supposed to appear? I can find nothing new in the program/project
root directory. This happens regardless whether I compile with
dmd or ldc2.
On Thursday, 27 July 2017 at 15:16:35 UTC, Eugene Wissner wrote:
Are there profilers that work well with dmd? valgrind? OProfile?
Yes, any sampling profiler works fine, e.g. perf on linux, Intel
VTune/AMD CodeXL on Windows.
Those directly monitor CPU performance counters and have a
negligible
On Friday, 22 December 2017 at 09:52:26 UTC, Chris Katko wrote:
DMD can use -profile and -profile=gc. But I tried for HOURS to
find the equivalent for LDC and came up with only
profile-guided optimization--which I don't believe I want. Yet,
if we can get PGO... where's the PROFILE itself it's u
On Sunday, 24 December 2017 at 02:48:32 UTC, Chris Katko wrote:
It would probably be really helpful to get a clear Wiki guide
for this information LDC. I'll write it myself if necessary
once I try your recommendations and test them out.
This would help us out a lot, thanks.
-Johan
x27;t believe I want.
Yet, if we can get PGO... where's the PROFILE itself it's
using to make those decisions! :)
Fine grained PGO profiling:
-fprofile-instr-generate
http://johanengelen.github.io/ldc/2016/07/15/Profile-Guided-Optimization-with-LDC.html
Function entry/exit profiling:
-finstr
On Saturday, 23 December 2017 at 12:23:33 UTC, Johan Engelen
wrote:
Fine grained PGO profiling:
-fprofile-instr-generate
http://johanengelen.github.io/ldc/2016/07/15/Profile-Guided-Optimization-with-LDC.html
Function entry/exit profiling:
-finstrument-functions
https://github.com/ldc-developers
tself it's using to
make those decisions! :)
Fine grained PGO profiling:
-fprofile-instr-generate
http://johanengelen.github.io/ldc/2016/07/15/Profile-Guided-Optimization-with-LDC.html
Function entry/exit profiling:
-finstrument-functions
https://github.com/ldc-developers/ldc/is
On Friday, 22 December 2017 at 09:52:26 UTC, Chris Katko wrote:
DMD can use -profile and -profile=gc. But I tried for HOURS to
find the equivalent for LDC and came up with only
profile-guided optimization--which I don't believe I want. Yet,
if we can get PGO... where's the PROFILE itself it's u
DMD can use -profile and -profile=gc. But I tried for HOURS to
find the equivalent for LDC and came up with only profile-guided
optimization--which I don't believe I want. Yet, if we can get
PGO... where's the PROFILE itself it's using to make those
decisions! :)
Thanks.
ers do not (the space is
available to expand into the block). There should be only one
allocation IMO.
So there should be a bug report written for this?
It all depends on what "allocations" means. I'd wait to find
out from someone who is familiar with the GC profiling.
uld be only one allocation IMO.
So there should be a bug report written for this?
It all depends on what "allocations" means. I'd wait to find out from
someone who is familiar with the GC profiling.
-Steve
On Tuesday, 17 October 2017 at 13:27:24 UTC, Steven Schveighoffer
wrote:
I don't know what "allocations" represents, but reserve
actually calls gc_malloc, and the others do not (the space is
available to expand into the block). There should be only one
allocation IMO.
-Steve
So there sh
On 10/17/17 2:14 AM, Tony wrote:
Found this unanswered question on StackOverflow.
This program:
import std.stdio;
void add(ref int[] data)
{
data ~= 1;
data ~= 2;
}
void main()
{
int[] a;
writeln("capacity:",a.capacity);
auto cap = a.reserve(1000); // allocated may be
Found this unanswered question on StackOverflow.
This program:
import std.stdio;
void add(ref int[] data)
{
data ~= 1;
data ~= 2;
}
void main()
{
int[] a;
writeln("capacity:",a.capacity);
auto cap = a.reserve(1000); // allocated may be more than
requested
assert(cap >
On 2017-07-28 11:30, Mario Kröplin wrote:
Our programs are intended to run "forever". 24/7 servers.
What's wrong with having a bool that determines if the loop should
continue running?
--
/Jacob Carlborg
On Friday, 28 July 2017 at 09:02:10 UTC, Temtaime wrote:
There's no "gracefully" way to kill a thread.
If your thread cannot join, then you're doing something wrong
Our programs are intended to run "forever". 24/7 servers.
the code with -profile, send a SIGTERM and call exit(0) from
my signal handler to exit the program. The problem is that I
get the profiling information only from the main thread, but
not from the other ones.
Is there a way to get the profiling information from all
threads before terminating the
signal handler to exit the program. The problem is that I
get the profiling information only from the main thread, but
not from the other ones.
Is there a way to get the profiling information from all
threads before terminating the program? Maybe some way to
finish the threads gracefully? or
profiling information only from
the main thread, but not from the other ones.
Is there a way to get the profiling information from all threads before
terminating the program? Maybe some way to finish the threads
gracefully? or manully call "write trace.log"-function for a thread?
On Thursday, 27 July 2017 at 14:44:31 UTC, Temtaime wrote:
Also there was an issue that profiling doesn't work with
multi-threaded apps and leads to a crash.
Don't know if it is fixed.
Was fixed two years ago:
http://forum.dlang.org/post/mia2kf$djb$1...@digitalmars.com
call exit(0) from
my signal handler to exit the program. The problem is that I
get the profiling information only from the main thread, but
not from the other ones.
[...]
You will need to run it single threaded.
If you want to use the builtin-profiler.
Are there profilers that work well with
problem is that I get
the profiling information only from the main thread, but not
from the other ones.
[...]
You will need to run it single threaded.
If you want to use the builtin-profiler.
Also there was an issue that profiling doesn't work with
multi-threaded apps and leads to a crash.
Don't know if it is fixed.
Exit is not "normal exit" for D programs so, do not use it.
Your threads should stop at some point to make able the app exit
successfully.
There's a "join" method. You can use it with your "done" variable.
I have a multi-threaded application, whose threads normally run
forever. But I need to profile this program, so I compile the
code with -profile, send a SIGTERM and call exit(0) from my
signal handler to exit the program. The problem is that I get the
profiling information only from the main
On Monday, 17 July 2017 at 20:36:58 UTC, Igor wrote:
I also tried "Very Sleepy" profiler but it only shows symbols
for main application and not for the DLL that it loads which is
also built with debug info.
Something that works very well is CPU profiling with CodeXL. It
use
On 17.07.2017 22:36, Igor wrote:
Is there a known limitation in profiling these or am I doing something
wrong?
When I try to run my application from VisualD (x64 build) with -profile
switch I just get Access Violation reported on WinMain function (actual
declaration, it doesn't ente
Is there a known limitation in profiling these or am I doing
something wrong?
When I try to run my application from VisualD (x64 build) with
-profile switch I just get Access Violation reported on WinMain
function (actual declaration, it doesn't enter its body). If I
build it with dub
le to have meaningful
profiling results for this case, given a large cost of calling
funcB? In release builds funcA and funcB are inlined, so profiler
cannot report on them individually (is it correct, or am I
misusing the profiler?). Profiling without inlining will show a
large cost of calling funcB
I'm not sure if it's what happening in this case but, in code
as simple as this, function calls can sometimes be the
bottleneck. You should see how compiling with/without -O
affects performance, and adding `pragma(inline)` to funcB.
When compiled with -inline, the profiler does not report the
On Saturday, 21 January 2017 at 12:33:57 UTC, albert-j wrote:
Now I dmd -profile it and look at the performance of funcA with
d-profile-viewer. Inside funcA, only 20% of time is spend in
funcB, but the rest 80% is self-time of funcA. How is it
possible, when funcB has three times the calculatio
Let's say I want to create an array of random numbers and do some
operations on them:
void main() {
import std.random;
//Generate array of random numbers
int arrSize = 1;
double[] arr = new double[](arrSize);
foreach (i; 0..arrSize)
arr[i] = uniform01();
On Monday, 18 April 2016 at 13:33:20 UTC, jj75607 wrote:
Hello!
Is it possible to start profiling on multithreaded app with Dmd?
https://issues.dlang.org/show_bug.cgi?id=14511 is open. I am
doing wrong or why this program segfaults if compiled with
profiler hooks?
import core.atomic
On Monday, 18 April 2016 at 13:45:20 UTC, Marc Schütz wrote:
Which platform/OS, dmd version, and command line are you using?
Windows7, DMD 2.071.0, run from Visual Studio 2013 Community +
VisualD 0.3.43
Which platform/OS, dmd version, and command line are you using?
Hello!
Is it possible to start profiling on multithreaded app with Dmd?
https://issues.dlang.org/show_bug.cgi?id=14511 is open. I am
doing wrong or why this program segfaults if compiled with
profiler hooks?
import core.atomic;
shared struct S
{
uint counter;
bool
Am Tue, 01 Mar 2016 02:30:04 +
schrieb Matthew Dudley :
> I'm working on a chess engine side-project, and I'm starting to
> get into profiling and optimization.
>
> One of the optimizations I've made involves some inline assembly,
> and I ran across some app
I'm working on a chess engine side-project, and I'm starting to
get into profiling and optimization.
One of the optimizations I've made involves some inline assembly,
and I ran across some apparently bizarre behavior today, and I
just wanted to double-check that I'm not d
I would like to get a view of the amount of memory that my
application requires over time, but this does not seem to be
trivial in D.
1) I assume the garbage collector could keep around memory that
my application is no longer using. If this is the case then no
external memory profiler is goin
On Sunday, 25 October 2015 at 12:21:33 UTC, tired_eyes wrote:
On Saturday, 24 October 2015 at 22:16:35 UTC, Vladimir
Panteleev wrote:
On Saturday, 24 October 2015 at 21:56:05 UTC, tired_eyes wrote:
Hi, are there any tools for compilation time profiling? I'm
trying to find what part of the
On Saturday, 24 October 2015 at 22:16:35 UTC, Vladimir Panteleev
wrote:
On Saturday, 24 October 2015 at 21:56:05 UTC, tired_eyes wrote:
Hi, are there any tools for compilation time profiling? I'm
trying to find what part of the code increases compilation
time and don't want to stum
On Saturday, 24 October 2015 at 21:56:05 UTC, tired_eyes wrote:
Hi, are there any tools for compilation time profiling? I'm
trying to find what part of the code increases compilation time
and don't want to stumble around.
There's this:
https://github.com/CyberShadow/DBui
Hi, are there any tools for compilation time profiling? I'm
trying to find what part of the code increases compilation time
and don't want to stumble around.
Is it possible to profile with LDC/GDC?
At least LDC lists it as only an "idea".
http://wiki.dlang.org/LDC_project_ideas
On Saturday, 31 January 2015 at 14:12:59 UTC, Phil wrote:
When trying to run my program with profiling enabled it dies
before the first line of my main function runs. Everything
works fine without profiling. I get the following stack trace:
thread #1: tid = 0x38de4, 0x00010008d985
1 - 100 of 135 matches
Mail list logo
