Built in metering

[ddyer0]

Inspired by the lack of metering tools for mobiles and javascript, I came up with a model that requires minimal code
modification. It occurs to me that this could be done automatically by parpavm, and maybe also the android recoder.

Here's the primitive skeleton of the profiler:
import java.util.Enumeration;

public class Meter {

public static SimpleHashCounter<String>counts = new SimpleHashCounter<String>();
public static int interval = 1000;	// nanoseconds between counts
public static boolean enable = true;	
public static void clear() { counts.clear(); }
public static int size() { return counts.size(); }
public static long lastTime = 0;
public static long now = 0;
public static void count(String c)
{	if(enable)
	{
	if(interval==0 || ((now=G.nanoTime())>lastTime+interval))
	{
	lastTime = now;
	int oldval = counts.get(c);
	int newval = oldval+1;
	counts.put(c,newval);
	}}
}

public static void report(int n)
{	if(enable)
	{
	Enumeration<String> keys = counts.keysByValue(true);
	while(n-- >= 0 && keys.hasMoreElements())
	{
		String key = keys.nextElement();
		int val = counts.get(key);
		G.print(key,"\t",val);
	}
	}
}

}

This requires a simple mod to the functions to be metered.
public int someFunction()
{
.... do whatever
Meter.count("copyTheBoardNow");
return value;
}

Obviously need to be smart about multiple exits and so on. Also could be extended to include per-function timing.

This could be communicated to parpavm by including a magic directive as a static variable in a class file, or
by a global directive to the build process.

[shai-almog]

The problem with this approach to profiling is that it impacts the profiled methods. Our optimizer can eliminate methods that don't include state mutation but once we do that it disables such optimizations and can waste your time with an illusion of data.

I'm not saying it isn't useful for some cases, but I think it would be problematic in the framework as people don't really read docs and would trust its results.

[ddyer0]

it would be something you turn on only when doing a tuning pass

[shai-almog]

I understand that. The value of a profiler is in its relative accuracy: methodA is 1.3x the speed of methodC and is invoked 3x more often.

Unfortunately, due to the optimizer in Codename One this approach you took will give you wrong results not just in absolute numbers but also in relative numbers as you're effectively disabling some optimizations that can lead you down the path of optimizing non-issues and possibly regressing the code.

The way profiling should work is through stack snapshots which doesn't impact the running applications optimization.

[ddyer0]

i agree but lacking a mechanism to do that, what else is possible? something is better than nothing.

[shai-almog]

We use the xcode profiler and Android based profiling. Especially the xcode profiling/memory analysis tools are really good.

[ddyer0]

doesn't apply to abnormal javascript performance debugging.

[shai-almog]

You can use chrome profiling to benchmark JavaScript which is what we use. But since we used it locally I hadn't noticed we don't publish mapping files as a standard part of the build which makes it harder to see a deobfuscated stack when profiling. We'll add the mapping file that would make it easier to read that output.

[ddyer0]

inded. i looked into the builtin profiler and saw nothing informative.