Hi Juan,<br><br><div class="gmail_quote">On Tue, Mar 3, 2009 at 5:28 AM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Andreas,<br>
<br>
Andreas Raab wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<div class="im"><br>
This is tricky with MessageTally. There are several issues to keep in mind, some of which you can fix, some of which you can't. Here we go:<br>
<br>
1) Observing all Processes<br>
--------------------------<br>
First, MessageTally only observes the block you are running, not the entire system. For example, if you were to profile this:<br>
<br>
done := Semaphore new.<br>
worker:= [<br>
10 timesRepeat:[World changed; displayWorld].<br>
done signal.<br>
] fork.<br>
MessageTally spyOn:[done wait].<br>
<br>
This is what you'd get:<br>
<br>
**Tree**<br>
100.0% {2367ms} primitives<br>
<br>
**Leaves**<br>
100.0% {2367ms} UndefinedObject>>DoIt<br>
<br>
Obviously it's not actually measuring what is going on during the period of time which is a real problem if you are trying to measure server load in general. But it's fixable.<br></div>
...<br>
</blockquote>
I found all this stuff very interesting and useful. Thanks!<br>
<br>
WRT issue 1), what I'd really like is the tally tree to have several roots, one for each forked process. Otherwise, the process that forks other processes would also have their tallies added to him (which is wrong, as it would appear to be using more time than it really did). Fixing this, MessageTally could give a better insight on cpu usage than #tallyCPUUsageFor:.<br>
<br>
To do this, I'd need to find out for a certain context in the sender chain, on which process it was running. (Then, when building the tally tree, I could know that I need to add a new root.) Do you know how to find out? I spent a couple of hours on this, and it seems it is not possible...</blockquote>
<div><br></div><div>When MessageTally runs to collect each tally the process that has been interrupted is the highest priority runnable process in the runnable process lists in ProcessorScheduler. You could implement it like this:</div>
<div><br></div><div><div>!ProcessorScheduler methodsFor: 'accessing' stamp: 'eem 3/3/2009 10:41'!</div><div>highestPriorityRunnableProcess</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>[quiescentProcessLists reverseDo:</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>[:each| each isEmpty ifFalse: [^each first]]] valueUnpreemptively.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>^nil</div><div><br>
</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>"| thisProcess interruptedProcess done |</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>thisProcess := Processor activeProcess.</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>done := false.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>[(Delay forSeconds: 1) wait.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> interruptedProcess := Processor highestPriorityRunnableProcess.</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> done := true] forkAt: Processor userInterruptPriority.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>[done] whileFalse.</div><div>
<span class="Apple-tab-span" style="white-space:pre"> </span>self assert: thisProcess == interruptedProcess"! !</div><div><br></div><div>So modify MessageTally (or better still create a subclass called MultiProcessMessageTally) that uses the above to manage a set of tallies for each process found while spying.</div>
<div><br></div><div>HTH</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Thanks,<br><font color="#888888">
Juan Vuletich<br>
</font><br>
Ps. I found that the problem with long primitives first appears in your 3.9.1 VM, and that BitBlt seems to slow down a bit in 3.7.1 and even more in 3.9.1. Are you planning to address this issues in the Windows VM?<br>
<br>
</blockquote></div><br>