7 Replies Latest reply: Jun 3, 2013 9:55 AM by 1011639 RSS

    Slow performance when moving between fields


      We are using an small piece of code to set the color of the all canvases when the form is loaded. This is causing a delay when you move from field to field. If we removed the code and leave the background color of the canvas as <Unspecified>, there is no delay. The problem is more obvious on those forms with multiple canvases(like 10 or more) and when is accessed via WAN. The code is only executed at the post-form trigger. We don't use java bean to change the color. Just the regular Set_Canvas_Property. Does anybody know why is that? We are using Oracle Forms

      Thanks in advance
        • 1. Re: Slow performance when moving between fields
          Michael Ferrante-Oracle
          I'm a little confused. You said, " +...small piece of code ... when the form is loaded+ ". But then you say, " +...only executed at the post-form trigger+ ". So which is it? Is the code executed when the form starts or exits? If the code is executing when the form exits, why would you be trying to change colors if the form is closing?

          Generally speaking, performance issues while navigating are the result of poor network performance and/or excessively customize validation or post item triggers. Such triggers should be tuned carefully and used sparingly so as to avoid such performance issues. In some cases, depending on the application design, you can delay validation by changing the form level property "Validation Unit". By delaying validation, some of the delay seen while navigating may be reduced. But be careful. This change will alter the validation behavior of your application.
          • 2. Re: Slow performance when moving between fields
            Thanks for reply Michael.

            We change the color in the PRE-FORM trigger. My bad. The code is only executed there but when the form has multiple canvases with many fields, and you move between fields, you can see the mouse cursor spinning. Like if something is being done in the database. This doesn't happen with small forms with one or two canvases. We know about the validations considerations but the slowness is also present on the fields that don't have any trigger.
            • 3. Re: Slow performance when moving between fields
              Michael Ferrante-Oracle
              Based on what you have described, I find it difficult to believe that the changing of colors is causing the problem. When you say "move field to field" are you suggesting that field A is on canvas A and field B is on canvas B and therefore the moving from field to field is actually canvas to canvas?

              You may find it helpful to enable tracing in the JRE and open the Java console. While navigating from field to field monitor the console and see how much, if any activity occurs. While in the same form and canvas, I would not expect more than one exchange in the console when navigating from field to field. If you are moving from a field on canvas A to a field on canvas B, likely there will be more network noise. If you are seeing excessing amounts of traffic, this is likely caused by your own code. In this case, you would need to carefully review the code and its logic.

              It might also be work looking closely at the client machines. Ensure that the machine is not underpowered. For example, a Windows 7 machine with 2gig of RAM is probably not going to perform well. Also, if you are using old JRE versions I would recommend using at least Java 6U45 or newer. If you are already using Java 7, be sure that you are using 7U21 or newer.
              • 4. Re: Slow performance when moving between fields
                Thanks for the tip, Michael. By turning the java trace on I'm able to see what is happening. Looks like the canvases are loaded into memory when I set the color. When I don't set the color, there is only on POST on the server like the one below when tabbing on the form. But when I set it, there are multiple ones(one per canvas, I think). Is there a way to avoid this?

                network: Connecting http://server:8888/forms/lservlet;jsessionid=QhkWRqvN0CFFvtRMvBfyPvD0bLCL8pd5KQL2gdH96RlJYgk8XNGn!-859986153 with proxy=DIRECT
                • 5. Re: Slow performance when moving between fields

                  Are you sure that you haven't accidentally created a form level post-text-item or pre-text-item triggerthat is firing for every field movement?

                  • 6. Re: Slow performance when moving between fields
                    Michael Ferrante-Oracle
                    Be careful to not misinterpret what you are seeing. The exchanges from client to server are necessary every time (well most times) something in the gui is changed and/or when some pl/sql must be executed related to something the user has done. So, for example, if you are in a text field and you click on a button within the same canvas this will produce traffic. If clicking the button causes pl/sql to execute, this may result in more traffic, depending on the code. If this then results in a new canvas and/or window to be displayed, even more traffic will be exchanged. Remember that the client UI must always be in sync with the server and visa-versa.

                    The only realistic way to avoid or minimize any of this is to write your code with some careful strategy. Consider carefully what actions you are taking against the UI and whether or not they are really necessary. If they are necessary, consider how, where, and when you are executing those calls.
                    • 7. Re: Slow performance when moving between fields
                      Thanks for join us, Tony.

                      No. I don't have a post-item-trigger at the form level. The problem is only when I access the canvases to change the color on the pre-form trigger. If I don't do it, the network traffic is reduced to only one post per field tabbing.

                      Michael, maybe I shouldn't say avoid the network traffic. What I meant was if there is a way to remove the canvases from memory so the applet doesn't have to repaint them all even if they haven't been shown on the screen. That's what I thinks it's being done. When a property is set on a canvas(or any object), doesn't it have to be loaded in memory?