User talk:Philosopher/Nasal introspection: Difference between revisions

Jump to navigation Jump to search

User talk:Philosopher/Nasal introspection (view source)

Revision as of 01:16, 15 September 2013

1,514 bytes removed ,  15 September 2013
m
→‎Race Condition ?: del() - fixed
mNo edit summary
m (→‎Race Condition ?: del() - fixed)
Line 29: Line 29:


: It was just to point out that setDefaultExtras won't enable profiling of threads other than the main one. I'm undecided as to whether or not to do it, but for now I thought it was safer to disable it. [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 18:55, 16 August 2013 (UTC)
: It was just to point out that setDefaultExtras won't enable profiling of threads other than the main one. I'm undecided as to whether or not to do it, but for now I thought it was safer to disable it. [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 18:55, 16 August 2013 (UTC)
== Race Condition ? ==
In its current form, the test.nas script will profile the entire session - when running it, I am getting this when exiting:
<pre>
Done processing stack
Found more work
Processing stack
Done processing stack
End thread 0 @ 0
Done
_dump
Warning: it looks like the thread didn't release the lock
Warning: it looks like the thread didn't release the lock
</pre>
When just profiling the test function itself, there's no such issue (less data & less threads presumably?):
<pre>
End thread 0 @ 0
**** Nasal garbage collection statistics: objects: 39231, references: 90961
Loading local weather routines...
**** Nasal garbage collection statistics: objects: 66574, references: 150574
**** Nasal garbage collection statistics: objects: 72047, references: 162214
**** Nasal garbage collection statistics: objects: 17427, references: 64621
Exit
Waiting
Done
_dump
</pre>
: For the record, I have no idea what a race condition is, but this warning is just because d[THREAD_RUNNING] == 1 – for some reason, this is correlated with debug.getFuncData(d[FUNCTION]) being nil. I don't understand this, but it doesn't seem to affect anything.
frame latency and frame rate get back to normal fairly quickly now, when profiling the entire sim, I am getting 180ms here - so, we'll still need to get it down by a factor of ~5-10.
The "call() with extras" doesn't seem to be affected when profiling the entire sim session, not sure how this works internally, recursion-wise and WRT file/data processing ?


== August 14 ==
== August 14 ==
Philosopher
395

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/62655"

Navigation menu