Shockingly slow form realisation - Forum - OpenEdge Development - Progress Community
 Forum

Shockingly slow form realisation

  • I've got a form that is taking upwards of 10s to initialise and display on the screen. I have put some "rough" diagnostics in, and the time is taken up by the initialize component call (5.5 seconds) and a data bound grid initialisation (5 seconds).

    This, obviously, is not acceptable to my users.

    The form in question has 5 ultragrid editors and a user-inherited infragistics data combo.

    On my development machine, the time to realise the form is about 2 seconds (not ideal, but manageable).

    The target machine is a quad processor dual-core dell 2950 with 4gb ram, running windows 2003 server (cpu% is 1%)

    The development machine is a quad-core intel with 4 gb ram, running vista.

    One wrinkle may be that I am running the development machine with OEA, but the target machine is a pure application machine (application runtime only, no development)

    Where can I begin to try and identify why these machines are running soooo differently ?

    The login screen of the application creates a default, hidden form, so I would assume that the .net runtime has been initiated before they get anywhere near this slow window.

  • meh. update.

    It's the init of the usercombo that is taking the time. I had a call to the init method in twice (once in the user control, and once in the form).

    Comment out the init, and the form itself takes milliseconds to load.

    Now, onto why the combo takes soooooooo long .

  • right. the line of code causing all the problems is

    THIS-OBJECT:DataSource = BindSource.

    the bindsource in question is created thus:

    where lv_Query is

    and lv_Columns is

    the UserCode table has only 200 records in it ...

    what do I do now ?

  • hacked the user control to use a temp-table instead.

    loop through all user records, buffer-copy to tt.

    create binding source for the tt instead of the database table

    it now takes 600 milliseconds to run. 10x faster that reading the database record directly. Even though I am reading all of the records in order to copy them to the TT !!

    Something is not right here.

  • Well, I doubt it's the processor of the target machine that's causing the problem. I also do not believe, that it's the fact, that it's a runtime license and not the dev license.

    Do you connect to the same instance of the database on both machines? Or are you using a local (shared memory) DB for dev and a remote DB on the target machine?

    Try a PRESELECT Query.

    How does the performence change, when you run the same Form a second time from the same runtime session? You have been assuming, that the .NET runtime is already loaded in the prowin32. But loading the required Infragistics libraries (~ one per namespace) takes also some time when a Control is used the first time. Even when the library for the "normal" input Controls is loaded, the UltraGrid assemblies needs to be loaded at it's first usage. The assemblies.xml file does not cause a preloading of the assemblies at runtime.

  • Do you connect to the same instance of the database

    on both machines? Or are you using a local (shared

    memory) DB for dev and a remote DB on the target

    machine?

    Local on dev, remote on target . However, it is a really small table, with only 200 records in total.

    Try a PRESELECT Query.

    Did already - no effect whatsoever.

    How does the performence change, when you run the

    same Form a second time from the same runtime

    session? You have been assuming, that the .NET

    it doesn't change.

    Look at my last post : reading the db table into a temp-table, and then binding the temp-table to the control is 10x faster than binding the db table to the control ...

  • Look at my last post : reading the db table into a

    temp-table, and then binding the temp-table to the

    control is 10x faster than binding the db table to

    the control ...

    I've seen that. The question is, how good is 10x faster compared to the local DB? Do you have some absolute numbers?

  • I've seen that. The question is, how good is 10x

    faster compared to the local DB? Do you have some

    absolute numbers?

    In my first post, I mentioned that it takes 10s on target and 2+s on the dev.

    However, I was calling the method that binds twice, so the times are really 5s target and 1s+ on dev.

    I've gotten target down to 600ms, and dev to around 200ms

  • and try as I might, I can't reproduce this against the sports database ...

  • Can you reproduce it on any other table for the same two databases? I.e., everything the same except the table?

    Assuming, of course, that you can still reproduce it on this table ...

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Can you reproduce it on any other table for the same

    two databases? I.e., everything the same except the

    table?

    Haven't tried that, because I simply can't reproduce this in any other code. I have taken the basics of the code around where the delay occurs, pasted it into the editor and it runs in 10ms or less ... even on the target machine

    Assuming, of course, that you can still reproduce it

    on this table ...

    Not yet I can't. I suspect that there is a bug lurking around here, one that only raises itself under a very particular set of circumstances

  • This is just a single table? Smells a bit like a non-indexed read or something.

    What about 1st pass versus second pass, i.e., faster once the records are in memory?

    Are the parameters of the two sessions equivalent, i.e., equal temp-table space to work in?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • This is just a single table?

    Yes, single table

    >Smells a bit like a

    non-indexed read or something.

    Nope, indexed - and there is only 200 records in the table

    What about 1st pass versus second pass, i.e., faster

    once the records are in memory?

    No difference.

    Are the parameters of the two sessions equivalent,

    i.e., equal temp-table space to work in?

    No temp-tables at all - just a pure, small, db table

    What is really strange is that there seems to be no rhyme or reason for this slowdown. I am trying to get the simplest code to show the problem, but am struggling to reproduce it.

  • If the simplest case does display the behavior, but the complex case does, I suppose you are stuck building the former up into the latter or tearing down the latter in the direction of the former until you see a change in behavior. Is ti possible to just start commenting out pieces of the complex case?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I haven't been able to reproduce against the sports database, but it definately related to the number of records in the query.

    If my query is

    then it takes 3000ms (3 seconds +) to execute the command

    Change the query to

    and the time is 10ms

    I must stress that there are only 200 records in total in this table. Not 2000 nor 20000, but 200

    If I do a "for each" on the table in the ABL, it takes less than 5ms to execute. I have even gone so far as to read through all of the records in the ABL just before the bind just to "preload" them into buffers, but it makes no difference. This "for each" read takes less than 4 ms to complete.

    So, I don't think that it's the database, nor the query as the ABL side works perfectly.

    This is the Infragistics.Win.UltraWinGrid.UltraCombo control that I am talking about, not the ComboEditor.

    It's also not the number of columns in the grid, nor the appearance.

    I am still trying to build this into a sports demo