I am confused as to how to interpret the "Self" slot in QCachegrind. Is it per call cost of a function or is it the total cost of a function when called x times where x is represented by the slot "called"?
(please see the image below)
Is 0.003 the cost of function when called once? or do I need to divide it by 2 ("called" slot) to get the function cost per call?
I was also looking for this answer also, found out that the Self that shows 0.003 is the cost for ALL the "Called". So for each call cost, theoretically it cost 0.003 / 2 . Although I think it's not that simple because different call to the same function can have different cost.
Incl. is the total cost of the function on that line, including the cost of all the functions called directly or indirectly by this function.
Self is the cost of the function itself.
See http://www.valgrind.org/docs/manual/cl-manual.html#cl-manual.use
(in particular section 6.1.1. Functionality) for more details.
Related
Let's suppose I have a function:
function doSomething(bytes memory _data){
...
}
How does the gas cost increase given the size of the function param _data?
Does it has a limit on how big _data can be?
check out this link http://www.scs.stanford.edu/18au-cs251/lectures/lecture10.pdf
In this lecture by Stanford, it says that the more the arguments, the more gas it consumes.
I wrote a program using JMX API to calculate JVM Usage percentage. Code makes use of 2 attributes of java.lang:type=Memory MBean (used and max attribute).
When I use the formula (used/max * 100) to calculate JVM Used Memory Percent, it gives me very different value than what is displayed in JMC Software. For example:
In JMC I see the Percentage as 45.3%. But used = 708MB and max = 6GB, which in turn in my code gives very less percentile.
From Task Manager > Process Tab > Memory Column, I looked for the corresponding TomEE memory usage which is closed to the usage attribute in JMC.
Need some guidance here on what is the right way to calculate or look for the JVM Usage Percentage. Why there is a difference of percentage in JMC attribute (HeapMemoryUsagePercent) and the percentage calculation in my code?
I like to schedule observations of variable duration (planning entity) into hourly time slots over several nights. I would need to impose that there are no gaps in particular groups, and need collectors for minimum, maximum and sum. Is there a workaround to have a groupBy with one groupKeyMapping and three collectors?
constraintFactory.from(OB.class)
.groupBy(OB::getGroupID, min(OB::getStart), max(OB::getEnd), sum(OB::getDuration))
I tried to workaround this using toList() and computing values myself but strangely it doesn't pass down a List<OB> but single OBs. The code below prints class my.package.OB
constraintFactory.from(OB.class)
.groupBy(OB::getGroupID, toList())
.filter((groupID, entries) -> {
println "=> ${entries.class} "
return true
})
This was a gap in our API (see PLANNER-2330). It is being addressed for OptaPlanner 8.3.0. We encourage you to upgrade - not only to get this particular feature, but also some nice performance improvements, assuming you're using higher cardinality joins.
I am programming newtons method, the following code snippet shows what I have done to the main function. I have a data structure with just the function, which is x^2+y^2 for now. the value for data.x0 is [1;1] (close to the solution) and the value for data.e is 0.01
The update xk is running away from the origin instead of towards it. In fact, I can get this code to work for a few problems when I specify data.x0 very close to a local minimum or inside a deep pit on the function. otherwise it diverges even for very simple functions.
My intuition tells me it is a result of using the hessian and gradient functions from the symbolic toolbox instead of analytic methods as I had been warned of. Any thoughts?
xk=data.x0
grad=gradient(data.f)
grad_xk=double(subs(grad,[x;y],xk))
hess=hessian(data.f)
norm_grad_xk=0;
for i=1:length(grad_xk)
norm_grad_xk=norm_grad_xk+grad_xk(i)^2;
end
norm_grad_xk=sqrt(norm_grad_xk)
mag_fun_xk=double(subs(data.f,[x;y],xk))
while (norm_grad_xk)>data.e*(1+abs(mag_fun_xk))
hess_xk=double(subs(hess,[x;y],xk))
invhess_xk=inv(hess_xk)
xk=xk-invhess_xk*grad_xk
% ll=horzcat(ll,xk)
norm_grad_xk=0;
for i=1:length(grad_xk)
norm_grad_xk=norm_grad_xk+grad_xk(i)^2
end
norm_grad_xk=sqrt(norm_grad_xk)
mag_fun_xk=double(subs(data.f,[x;y],xk))
end
I am using valgrind callgrind to profile a program on gtk. And then I use kcachedgrind to read the result. I have captured an update a screenshot of kcachedgrind here: http://i41.tinypic.com/168spk0.jpg. It said the function gtk_moz_embed_new() costed '15.61%'.
But I dont understand how is that possible. the function gtk_moz_embed_new() literally has 1 line: and it is just calling a g_object_new().
GtkWidget *
gtk_moz_embed_new(void)
{
return GTK_WIDGET(g_object_new(GTK_TYPE_MOZ_EMBED, NULL));
}
Can you please help understanding the result or how to use kcachedgrind.
Thank you.
If i remember correctly that should mean (more or less) that function gtk_moz_embed_new() was executing 15.61% of the time the the app was running.
You see, that function returns an inline call to other functions (or classes or whatever) that also take time to execute. When they are all done it's then that the function gtk_moz_embed_new() acutally returns a value. The very same reason it takes main() 99% of the time to execute, it finisesh execution after all included code in it is executed.
Note that self value for the gtk_moz_embed_new() is 0 which is "exclusive cost" meaning that function it self did not really took any time to execute (it's really only a return call)
But to be exact:
1.1 What is the difference between 'Incl.' and 'Self'?
These are cost attributes for
functions regarding some event type.
As functions can call each other, it
makes sense to distinguish the cost of
the function itself ('Self Cost') and
the cost including all called
functions ('Inclusive Cost'). 'Self'
is sometimes also referred to as
'Exclusive' costs.
So e.g. for main(), you will always
have a inclusive cost of almost 100%,
whereas the self cost is neglectable
when the real work is done in another
function.