On Nov 4 2017, Christian Kellermann wrote:
Given that I presumed to compile with -no-trace and focus on ressource
conservation: No. I feel, I have been warned. No, I do not see a point in
runtime cost for debug features I could previously disable completely.
* J?rg F. Wittenberger [171104
On Sat, Nov 04, 2017 at 08:06:59PM +0100, Jörg F. Wittenberger wrote:
> Just wondering. If memory usage was the concern, why not simple compile
> without tracing?
>
> This way we pay one more slot per thread. Plus some lookup. What do we earn?
>
> Maybe I'm missing something?
Like Christian said
* J?rg F. Wittenberger [171104 20:07]:
>
>
> Just wondering. If memory usage was the concern, why not simple compile
> without tracing?
>
> This way we pay one more slot per thread. Plus some lookup. What do we earn?
>
> Maybe I'm missing something?
You will miss helpful error messages?
--
Just wondering. If memory usage was the concern, why not simple compile
without tracing?
This way we pay one more slot per thread. Plus some lookup. What do we earn?
Maybe I'm missing something?
Joerg
On Sat, Oct 28, 2017 at 09:01:15PM +0200, felix.winkelm...@bevuta.com
wrote:
This is int
On Sat, Oct 28, 2017 at 09:01:15PM +0200, felix.winkelm...@bevuta.com wrote:
> This is intended to fix #1356: threads may be retained too long in the trace
> buffer, because some sort of method is required to extract the call chain
> for a specific thread (multiple threads can create entries in the
This is intended to fix #1356: threads may be retained too long in the trace
buffer, because some sort of method is required to extract the call chain
for a specific thread (multiple threads can create entries in the trace buffer
and thus must be distinguished).
Now a thread has an additional slot
