I've run into a limitation of the ABL Profiler, when using in an OO application:
The Profiler doesn't distinguish between overloaded versions of the same method, all overloaded versions are considered the same: the method appears only once in the 'module' part of the profiler dump, and all further references (Call tree, line summary...) refer to that instance. This makes it very hard to build an automated view on that dumped information.
e.g.
CLASS ProfilerTestClass:
METHOD PUBLIC VOID run():
overLoadedMethod("X").
overLoadedMethod("X", "Y").
END.
METHOD PUBLIC VOID overLoadedMethod(INPUT a AS CHARACTER, INPUT b AS CHARACTER):
/* do something */
END METHOD.
METHOD PUBLIC VOID overLoadedMethod(INPUT a AS CHARACTER):
overLoadedMethod(a, "?").
END METHOD.
END CLASS.
This gives a profiler output like this:
1 /* some method */ 2 /* some method */ 3 /* some method */ 4 "ProfilerTestClass" "c:/temp\dbg_ProfilerTestClass_00a12848" 42118 5 "run ProfilerTestClass" "" 0 6 "overLoadedMethod ProfilerTestClass" "" 0 . 0 0 2 1 2 21 3 1 3 6 4 1 3 8 5 1 /* Call of run method */ 5 18 6 1 /* Call of overLoadedMethod with 1 parameter */ 5 19 6 1 /* Call of overLoadedMethod with 2 parameters, but this cannot be derived from this info */ 6 31 6 1 /* Internal call to overLoadedMethod with 2 parameters, but this cannot be derived from this info. */
Does anyone have an idea of how to cope with it?
Any settings of the profiler that can be tweaked?
I've run into a limitation of the ABL Profiler, when using in an OO application:
The Profiler doesn't distinguish between overloaded versions of the same method, all overloaded versions are considered the same: the method appears only once in the 'module' part of the profiler dump, and all further references (Call tree, line summary...) refer to that instance. This makes it very hard to build an automated view on that dumped information.
e.g.
CLASS ProfilerTestClass:
METHOD PUBLIC VOID run():
overLoadedMethod("X"). overLoadedMethod("X", "Y").END.
METHOD PUBLIC VOID overLoadedMethod(INPUT a AS CHARACTER, INPUT b AS CHARACTER):
/* do something */
END METHOD.
METHOD PUBLIC VOID overLoadedMethod(INPUT a AS CHARACTER):
overLoadedMethod(a, "?").
END METHOD.
END CLASS.
This gives a profiler output like this:
1 /* some method */
2 /* some method */
3 /* some method */
4 "ProfilerTestClass" "c:/temp\dbg_ProfilerTestClass_00a12848" 42118
5 "run ProfilerTestClass" "" 0
6 "overLoadedMethod ProfilerTestClass" "" 0
.
0 0 2 1
2 21 3 1
3 6 4 1
3 8 5 1 /* Call of run method */
5 18 6 1 /* Call of overLoadedMethod with 1 parameter */
5 19 6 1 /* Call of overLoadedMethod with 2 parameters, but this cannot be derived from this info */
6 31 6 1 /* Internal call to overLoadedMethod with 2 parameters, but this cannot be derived from this info. */
Does anyone have an idea of how to cope with it?
Any settings of the profiler that can be tweaked?
Flag this post as spam/abuse.