Any chance to implement the routine "profiler"?

[brandy125]

I would need the routine "profiler" in order to debug a speed issue in my program.

Any chance to implement it (soon)?

[alaingdl]

We discussed that in the past, and it was said it would be difficult to have it given the way the code was written. May be new idea

Do you have a way to "bisect" the function or the lines which are slow ? Did you compare to IDL or FL ?

On which platform do you have the problem ? If OSX please re-compile with the current Git version (slow loops issue solved !)

[brandy125]

thanks for the fast answer. I have only an old version of IDL that does not know about “list”. FL I have but I could not get it to run because it uses the system routine “read_tiff” that does not know about /geotiff keyword. Do you know how to compile the GDL “read_tiff” instead of the system routine in FL? That would help for now. I use many loops so I will give the new GDL version a try.

…

On 2. Apr 2024, at 08:24, Alain ***@***.***> wrote: We discussed that in the past, and it was said it would be difficult to have it given the way the code was written. May be new idea Do you have a way to "bisect" the function or the lines which are slow ? Did you compare to IDL or FL ? On which platform do you have the problem ? If OSX please re-compile with the current Git version (slow loops issue solved !) — Reply to this email directly, view it on GitHub <#1795 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOC5K6GUFZVADTQGOXTLTGLY3KIPPAVCNFSM6AAAAABFTFEDM6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DSOBSG42DC>. You are receiving this because you authored the thread.

[alaingdl]

• I don't used LIST() and have no background on that, 99% of my work is processing 2D, 3D or 4D data cubes !

• as long as the function read_tiff.pro in src/pro is calling the internal TIFF_READ function, you cannot using it in FL :(

GDL> #tiff_read
Internal FUNCTION : res=TIFF_READ([1 Arg],RED,GREEN,BLUE,CHANNELS,DOT_RANGE,GEOTIFF,
ICC_PROFILE,IMAGE_INDEX,INTERLEAVE,ORIENTATION,PHOTOSHOP,PLANARCONFIG,SUB_RECT,VERBOSE)

[GillesDuvert]

Although feasible, PROFILER would be some work to implement. But GDL is open-source, so anybody can compile or use it with a profiler (gprof, or even valgrind).
If this is of any help, note that some GDL functions or procedures that IDL has compiled, are interpreted in GDL. Write_tiff is an example, when read_tiff has been implemented in C++ (internal function tiff_read).

[brandy125]

I will give it a try. Actualy my program is not very well written. Many loops and millions of “total()”, “acos()”, “cos()”, “exp(complex(0,big_array))” over big arrays. I would like to identify which of them has the biggest impact. Some formulas could be written differently. The IDL “profiler” was always nice to identify that things but unfortunately I have no access to it. Actually I would not need a complete “profiler” output, maybe knowing how much each of that functions was called could give a hint already.

…

On 6. Apr 2024, at 07:21, Giloo ***@***.***> wrote: Although feasible, PROFILER would be some work to implement. But GDL is open-source, so anybody can compile or use it with a profiler (gprof, or even valgrind). If this is of any help, note that some GDL functions or procedures that IDL has compiled, are interpreted in GDL. Write_tiff is an example, when read_tiff has been implemented in C++ (internal function tiff_read). — Reply to this email directly, view it on GitHub <#1795 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOC5K6FIMIMJIASPTLVLVULY37EDJAVCNFSM6AAAAABFTFEDM6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAMRYG44TG>. You are receiving this because you authored the thread.

[GillesDuvert]

If you have already an idea of the possible culprits, and a typical loop size, doing separate tests like we do often
tic & for i=1,100000L do b=myfunc(a) & toc is sufficient to estimate what part one basic, e.g., acos() or exp() "weight" plays in the total time. (note: these basic functions should be already very optimized).
Among the culprits:

• GDL loops are 3 times slower than IDL (first test of time_test4)
• Some basic text-handling (read, write, format) functions are very slow.
• CONGRID is terrible.
• With a large number of threads, use of --smart-tpool option is mandatory.

We are of course interested in knowing if a particular function is terribly slow.

[alaingdl]

As Gilles said, most of the basic operations are already quite well optimized ! But large real codes are very efficient to deter problem
(this is why two year ago we rewrote some string related operation : the c++ class is super slow compare to basic C operations for strings.