1. François Rossignol
  2. PowerBuilder
  3. Friday, 11 January 2019 11:22 AM UTC



I'll try to summerize the problem I encounter

I use PowerBuilder 2017R3


I have a window

That window has 3 arrays of userobjects in the instance variables

u_datawindow idw_reports[] (the report datawindow)

u_sort_options iuo_sort_options[] (contains two datawindow)

u_report_criterias iuo_report_criterias[] (can contain anything from checkboxes radio buttons datawindows etc.)


the window has a menu that contains a list of reports.

The same window is used for several lists of reports (menu is loaded dynamicaly)


When I click on the menu I call a function open_report that acts like that.


if a_report_is_opened then 

this.idw_reports[displayed_report_index].visible = false

this.iuo_sort_options[displayed_report_index].visible = false

this.iuo_report_criterias[displayed_report_index].visible = false

end if

if report_has_already_been_openened_once then

this.idw_reports[report_index].visible = true

this.iuo_sort_options[report_index].visible = true

this.iuo_report_criterias[report_index].visible = true




this.openUserObject(this.iuo_report_criterias[report_index],u_report_criterias ,...)

end if

The openuserobject on iuo_report_criterias may trigger some post_construtor events.


Works great but I have performance issues

Each time I open a new report it takes exponentialy longer to open. if you open a report in first it will take a second, if you open the same report in 5th it will 10 seconds. It does seem it's not the actual open process but the application hangs.


During my tests:

I did not retrieve the report datawindow to avoid any unecessary overlay.

I activated the Trace with a trace all activities.

The open_report function always performs the same (modulo a few milliseconds) wether you open the same report in first or 5th or 10th)

I tried to time the open_report function and the result is consistent with the trace.

The application will hang the same wether I openuserObject or visible = true

The post_construtor events always performs the same as well.

You can see on the screen that objects are correctly displayed before the application hangs.


I checked the performance of the calls in the trace file, and this is where I'm at a loss, there is nothing there consumming the CPU appart from the opens and post_constructor, and they perform consistently across the board.


That means there os something that freezes my application for a few seconds (more and more with each call) and that is not traced by the PB Trace.


In my open_report function if I replace the visible = false with closeUserObject() the hang is less visible but it still happens.


if I drop my arrays for a non array instance variable of each type there is no problem.

That lead me to think that the problem comes from the object arrays getting bigger (even if the object in it are being destroyed).


The non array approach is not an option because I do not want my users to have to re-retrieve the reports they already have retrieved. I do not want them to lose the report criterias they filled each time they want to open a news report in the same window.


I need help to be able to pinpoint where the performance issue is coming from.

If you have any advice on how I could to the same thing without the object arrays I'd be gratefull.



Accepted Answer
François Rossignol Accepted Answer Pending Moderation
  1. Monday, 21 January 2019 11:02 AM UTC
  2. PowerBuilder
  3. # Permalink

Finally found where the problem came from.


My criteria objects are filled with an on the fly search functionnality I implemented.

Each object that has the on the fly search will preopen (openUserObject) (bit of a design flaw but it wasn't originally meant to be used that way) an invisible search result list that is filled when the search is performed.

The list is a customvisual containing a datawindow which covers fully the userobject.


The background of the user object was transparent. I changed the background to a solid color and the problem was fixed.

And because when I tested the "moving the objects around" I did not think of the search result objects I still had quite a few transparent objects, although invisible in the visible area of the window.


It seems to me that overlaying userobjects with transparent background takes quite a toll on performances event when the objects are invisible.


Thanks to all who tried to help.

There are no comments made yet.
François Rossignol Accepted Answer Pending Moderation
  1. Thursday, 17 January 2019 14:05 PM UTC
  2. PowerBuilder
  3. # 1

Thanks Brad, I did not know about the rt_dbg_outfile

But it slow the application so much that I can't get any good informations out of it.


"Funny" thing happening in the window


for each report I have a report datawinwond and optionnaly two userobjects

The window will either display the report or the userobjects

I have a toggle button to switch what I display.

Appart from always displayed objects in the window I'll display either one report DW or two user objects

the other objects in the arrays are hidden

After a very few report have been openened the first time I hit the toggle button to swtich from one view to another for a repport the application hangs a few seconds. Then it all goes smoothly the next time I hit the switch for that report.

If I open another report and go back to a report where I previously hit the switch it goes smoothly too.

Now if I open my objects outside of the visible area of the window I don't experience the freeze time when hitting the toggle button (in that case it will move the objects into or outside the visible area along with the .visible=true/false).


that makes me think that the freeze might have something to do with drawing the screen.

Even if I open my objects outside the visible area I still experience the delay after the opening of the objects.

Tried to play with setRedraw but no luck.


To keep speed from being a factor, I used a 1.5G RAMDrive (by ImDisk) I have for temporary files (I compile PB apps from it, the difference in compile speed vs that from our network is huge). With the file on the ram drive, writing large qtys of debug data is quick and doesn't seem to noticeably slow down the app.

Ideally, turn the debugger ON only when you need it. That keeps it from getting in the way while you're getting set up to test the problems.

What happens if you move the objects onto screen AFTER creating them off screen? Is there still a delay when they become visible?
  1. Brad Mettee
  2. Thursday, 17 January 2019 15:01 PM UTC
There are no comments made yet.
Brad Mettee Accepted Answer Pending Moderation
  1. Monday, 14 January 2019 16:56 PM UTC
  2. PowerBuilder
  3. # 2

There is an internal debugger that can be used, but not sure how much help it may be. It's undocumented and might take some trial and error to see which options give you the most output from object creation. Turning on the debugger will open a console window with results of current activities. DO NOT CLOSE THIS WINDOW, it will immediately end whatever you have running in the IDE or compiled EXE without any warning, and no events will be fired (it's like sending 'kill -9' in the *nix world, or "end task" in windows task manager).


1 - turn on logging console (warning, closing this will close PB dev env with no warnings or close events getting triggered, ditto for running exe)
3 - show memory related calls
20 - show internal calls
21 - pbl management - by itself, doesn't create log
23 - show internal calls
26 - show internal calls
27 - function pointer loading, structure pointer assigns
29 - object group processing
30 - show function/event calls
31 - show pcode trace
32 - show external func calls
34 - show pcode line execution
38 - event queue processing
42 - show internal calls
43 - global symbol references dump
44 - class ref
45 - routine symbol table dump
int ii_options = {1, 30, 32, 34}  // set this to whatever combination of flags you want from the above list

long l
sting ls_filename = "rt_debug.txt"

l = rt_dbg_outfile(ls_filename) // debug output file is required, or nothing works
for l = 1 to upperbound(ii_options)
l = rt_dbg_on()			// enable rd_debug

// open objects here

// clean up
for l = 1 to upperbound(ii_options)
l = rt_dbg_off()		// disable rt_debug
There are no comments made yet.
François Rossignol Accepted Answer Pending Moderation
  1. Monday, 14 January 2019 08:00 AM UTC
  2. PowerBuilder
  3. # 3



First of all thank you for your answers.


No, I'm not running low on ressources, this is a new application which is still under development.

Yes, I loop for closeUserObject during the close event of the Window.

Yes, on the cirteria user object there can be anything and each one of them is different.

ExportJSON is not an option for the report DW because we have some Composite and Crosstab.

I know about the GetFullState/SetFullState which we used in a previous application but it crashes the application when the data is "large-ish".


For my tests, I open the application (either IDE or compiled version) , go straight to the report Window and open different reports (without retrieving them) this way I make sure it's not about ressources or bad cleanup.


What bothers me is that the aplication hangs and consummes CPU that is unaccounted for in the PB trace file.


I'm going to make my own timestamped trace to identify where the problem happens.




There are no comments made yet.
Olan Knight Accepted Answer Pending Moderation
  1. Friday, 11 January 2019 15:51 PM UTC
  2. PowerBuilder
  3. # 4

Francois -

   Are you running low on platfrom resources after the 5th+ OPEN call?

   I have found that for my somewhat large corporate application it will lock up when I have too many other windows open on the platform. The app behave appropriately for a while, then just freezes. Expanding the platform resources resolved this issue for us.



There are no comments made yet.
Kevin Ridley Accepted Answer Pending Moderation
  1. Friday, 11 January 2019 15:31 PM UTC
  2. PowerBuilder
  3. # 5

Do you have different buttons/functionality on each userobject?  If not you could save each datawindow either using GetFullState to a blob, or ExportJSON to a string and recreate the DWs as needed.

There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 11 January 2019 14:45 PM UTC
  2. PowerBuilder
  3. # 6

Hi  François;

   At the closure of this Window dialogue - are you using the CloseUserObject() method to clean up all the UO resources?

Regards  ... Chris

There are no comments made yet.
  • Page :
  • 1

There are no replies made for this question yet.
However, you are not allowed to reply to this question.