Profiling 3.0 applet ...

cbarber 115 posts since
Sep 27, 2007

1. Re: Profiling 3.0 applet Oct 7, 2008 5:56 AM

If you have a PRO license for the 3.0 IDE, you should be able to use the profiling tool. However, if your problem is during loading you might have to instrument your applet to turn profiling on and off while loading:

{curl 3.0 applet}
{import * from CURL.IDE.PERFORMANCE}
{initialize-performance-profiling "data.cprof"}
{start-performance-profiling}
... rest of applet ...
{stop-performance-profiling}
{finish-performance-profiling display-in-ide? = true}

BTW, why are you still using 3.0? We have made a number of performance improvements in the subsequent releases. It is possible that using a newer version of Curl will at least partially alleviate your problem.

Kamal 139 posts since
Oct 17, 2007

2. Re: Profiling 3.0 applet Oct 7, 2008 6:02 AM

You could also try "enable-memory-trace" API to see what objects are getting created. Maybe by looking at what objects that are getting created you may get an idea if there is something you are creating too many times or too often which you do not expect.

tiju 102 posts since
Oct 17, 2007

3. Re: Profiling 3.0 applet Oct 7, 2008 6:11 AM

in response to: cbarber

I am stuck with a OOM support-issue for a client. The code is using Tables !!

Found out where exactly the time is taken and tried a similar code like the below in a fresh applet. The Table.add is taking so much time. Any quick work-around I can implement for this?

 


{value
    let size-a:int = 3000
    let size-b:int = 90
    let t:Table = {Table halign="right"}
    {for i:int = 1 to size-a do
        {for j:int = 1 to size-b do
            {t.add
                row = i - 1,
                column = j - 1,
                i * j
            }
        }
    }
    t
}

Will using the RecordGrid help me?

tiju 102 posts since
Oct 17, 2007

4. Re: Profiling 3.0 applet Oct 7, 2008 6:29 AM

in response to: Kamal

Outing to the standard output in curl is too costly. In java, a System.out.println is pretty quick. I have earlier tried a huge for loop with and without {dump}/{output} compared against a similar for lop in java with system.out.println. While only the for loop in curl is faster than the java, a dump/output inside the for loop strugles to finish

tiju 102 posts since
Oct 17, 2007

5. Re: Profiling 3.0 applet Oct 7, 2008 6:47 AM

in response to: tiju

Can we see the console output in any log file in the system?

RajivGu 82 posts since
Apr 2, 2008

6. Re: Profiling 3.0 applet Oct 7, 2008 6:48 AM

in response to: tiju

I m completely agree with your observation, logging method output and and dump are very slow.

Usually I prefer to comment this logging method of curl after code finish and use it only for debugging.

Hope curl will address this issue.

Also, I m looking for an API which could output the Traces to some file (log file).

So let me know if any body aware with it in curl.

Thanks

Rajiv.

cbarber 115 posts since
Sep 27, 2007

7. Re: Profiling 3.0 applet Oct 7, 2008 7:48 AM

in response to: tiju

I am not surprised to hear that 'dump' and 'output' are slow. Because Curl gives each applet its own separate memory area, writing to the console involves sending messages to the process that manages the console. I think you may also find that it will run faster if the console window is not currently open. In any case, you may find that writing the output to a file instead of the console may be faster. If your applet is privileged you can do this by setting stderr and stdout to point to your file:

def my-log-file = {append-open "log-file.txt"}
{set-stdout my-log-file}
{set-stderr my-log-file}
...

Kamal 139 posts since
Oct 17, 2007

8. Re: Profiling 3.0 applet Oct 7, 2008 8:05 AM

in response to: tiju

Table.add is not taking most of the time. There two big components here:

1. Adding elements to the Table. This includes the time of adding other graphical elements to the table that will eventually help in table layout.
2. Adding the Table to the graphical hierarchy that also includes the time for layout and drawing.

Experiments show, that out of the total time one third is taken by step 1 and about the remaining two third by step 2.

Yes, RecordGrid should help here. You should see a huge drop in time in both the above mentioned steps. This is because RecordGrid only adds those elements to the graphical hierarchy that it can show. When you scroll to reveal other elements, it will reuse its cells to show the other elements. So the number of elements it needs to layout will be in very small (depending upon how many cells are shown at a time).

cbarber 115 posts since
Sep 27, 2007

9. Re: Profiling 3.0 applet Oct 7, 2008 8:34 AM

in response to: tiju

Yes, you really want to be using RecordGrid for something like this. Table is only intended for formatting small tables that will fit in one screen. There may be some trick to making very large tables such as this faster, but it will always be much slower than using a RecordGrid.

tiju 102 posts since
Oct 17, 2007

10. Re: Profiling 3.0 applet Oct 15, 2008 9:02 PM

in response to: cbarber

Wow! I never knew this.

<code>def my-log-file = {append-open "log-file.txt"}
{set-stdout my-log-file}
{set-stderr my-log-file}</code>

tiju 102 posts since
Oct 17, 2007

11. Re: Profiling 3.0 applet Oct 7, 2008 10:20 PM

in response to: Kamal

Thanks Kamal and Christopher. So now I know that RecordGrid is exactly what I need to use.

I was thinking of implementing a grid that makes only the required cells that need to be displayed. But for this, we will need to write code for handling the scroll, to calculate the number of rows that can be displayed at a time as my layout is flexible and to determine which set of rows to display currently. If the RecordGrid reuses cells, it will defenitely help. But still, 3000 x 90 objects (as per my earlier code above) will be created and held in memory, right? Each object inherits a Frame in the actual code.

RajivGu 82 posts since
Apr 2, 2008

12. Re: Profiling 3.0 applet Oct 7, 2008 10:30 PM

in response to: tiju

Hi Tiju,

I don't think this will be the case, as per my understanding of curl,

It follows the lazy loading of objects in memory, so when object are not currently used may

be swaped out from the memory and will be laoded back when required.

Kamal ....please correct me, if i m wrong...

Thanks

Rajiv.

carl 74 posts since
Oct 17, 2007

13. Re: Profiling 3.0 applet Oct 8, 2008 12:38 AM

in response to: tiju

But still, 3000 x 90 objects (as per my earlier code above) will be created and held in memory, right?

No, those are precisely the problems that RecordGrid is designed to solve for you.

The existing RecordGridUIs all create only (about) as many cells as are visible in the grid, at least in the vertical dimension. When "scrolled", instead of new cells being created or cached cell brought into view, the existing cells are left in place and their contents refreshed. See RecordGridCell.refresh-data . So if you have an existing case that uses static Frames, the major change will be to make some sort of RecordGridCell that's mutable. And creating a RecordSet with the base data.

In your example, if you have a RecordGrid 20 rows high, then you'd have 20 by 90 cells in existence. Initially, those would be displaying the first 20 Records. If you scrolled to the last row, each cell would be notified that it was now displaying a new row -- for example, the last visible row would be driven by the data in the last Record -- then told that it should refresh its contents to show those new values. You'd still have 3000 by 90 pieces of data in memory (unless you have custom RecordGridColumn s that manage to use less) but not the overhead of keeping visual representations for each at all times.

This Question is Answered

Profiling 3.0 applet

Oct 7, 2008 2:27 AM

Actions

More Like This