Is there any practical limit to the size of a project? e.g. Is performance better of worse as project size heads toward infinity?
I can see issues re managing a large number of screens in the designer, but are there any other issues that you know of?
Thanks.
Nope. The only practical limits are memory usage (shouldn’t be significant, non-open windows consume very little RAM) and download time (the progress bar that goes across the bottom of the login screen is when you’re downloading your project).
As an aside, very large windows (many hundreds of different components on the window) have pretty poor loading performance, especially on slower machines. We’re aware of this, and performance should improve in the future as we improve the serialization algorithm. This typically isn’t a big issue, however, because you can set the window to cache and then it will only have to load once.
Carl, speaking of the serialization algorithm, can you suggest a way to make this a little more transparent when the screens are loading the first time? For instance, during customer training my screens look pretty scrambled the first time they load, and they understand that everything will look fine from that point on. But just from a cosmetic point of view, can you think of a way to hide this “serialization” completely?
Would an opaque overlay with a little hourglass that was bound to a global variable work? Or a script that made all components invisible while displaying a “wait” message? Obviously this would only need to be done the first time (everyone is impressed with the responsiveness of the screens once they are loaded), but I didn’t know if there was a screen property that I could use.
I’m sorry, what do you mean when you say things look “scrambled”??
There is an ‘hourglass’ that shows when the screens are loading - its the upper right-hand side of the screen.
Please explain.
Thanks, Carl.
Ok, by scambled I mean that almost every image component appears at about 50% of actually size, so they are all detached from each other. Also, any component who’s “visible” property or style is bound to a tag appears as a light green box. It looks pretty chaotic.
There is an hourglass on the screen that launches the screens, but this goes away once the new screen appears. The new screen just sits there with no indication that anything is happening, and then suddenly everything “clutches in” (their words) and looks fine. One screen, which I wouldn’t say has many components at all, sits this way for 17 seconds. And as I said, the screens swap very quickly from this point on.
This is the kind of thing I like to hear about!
The size sounds like correct behavior. Objects open at the size that they were serialized (saved) at, then resize based on layout. Saving screens in the designer at a closer resolution to what you’re running at, or using the Anchored Layout may help.
It sounds like something is seriously wrong. 17 seconds to open a window after downloading it! How fast is your next slowest window to load? I’m guessing that you may have some slow queries, script, or other strange thing occurring (serialization problem).
I’m guessing that the “light green box” refers to a certain SQLTags overlay based on some quality code (410?) that’s waiting for the data. It makes sense that the bindings don’t get resolved until after the de-serialization.
One last thing to try. Back up your window in case of the rare event that this actually fixes it. Tools->Advanced->Reserialize Windows.
[quote=“Step7”]Ok, by scambled I mean that almost every image component appears at about 50% of actually size, so they are all detached from each other. Also, any component who’s “visible” property or style is bound to a tag appears as a light green box. It looks pretty chaotic.
There is an hourglass on the screen that launches the screens, but this goes away once the new screen appears. The new screen just sits there with no indication that anything is happening, and then suddenly everything “clutches in” (their words) and looks fine. One screen, which I wouldn’t say has many components at all, sits this way for 17 seconds. And as I said, the screens swap very quickly from this point on.[/quote]
[quote="nathan"]This is the kind of thing I like to hear about!
The size sounds like correct behavior. Objects open at the size that they were serialized (saved) at, then resize based on layout. Saving screens in the designer at a closer resolution to what you're running at, or using the Anchored Layout may help.
[/quote]
I need relative layout, and there isn't really a standard resolution that I will be running these screens at. I understand what is happening, but I'm wondering if there is a way to hide it while it's happening.
Ok, I'll buy that. But it really seems to be hinged on the number of images on the screen. One screen that has no images at all launches almost immediately. The one that takes 17s has about 20 images, and the one that takes about 5 seconds has about 6 images. I am kind of a speed junky when it comes to writing tight code, so I don't think I have scripts or queries that could be doing this, especially since these screens don't do a whole lot anyway.
[quote]
I'm guessing that the "light green box" refers to a certain SQLTags overlay based on some quality code (410?) that's waiting for the data. It makes sense that the bindings don't get resolved until after the de-serialization.[/quote]
Yes, that's how it seems to work. But it adds to the effect that the screen looks jumbled during initial launch.
[quote]
One last thing to try. Back up your window in case of the rare event that this actually fixes it. Tools->Advanced->Reserialize Windows.[/quote]
Ok, I went there, but chickened out when I saw the pop-up window "Really Re-Serialize?" and the message asking "Are you sure you want to re-serialize all windows?". Is this dangerous? Can something go wrong?
I am opening and closing the windows all the time in the designer, so I assume that they are getting re-serialized then anyway, right?
Thanks Nathan.
No, re-serializing isn’t particularly dangerous unless you’ve made a bunch of changes without saving. It’s basically opening/closing all windows. I was going out on a limb on the serialization error guess.
It sounds like you’ve nailed the problem on the images. How big are the files? I’d guess that you could resample/rescale them down to look nearly identical, but take up a much smaller footprint. Try irfanview. It’s free. I typically recommend .png, but it depends on file type (photos tend to be better in .jpg, for example).
You may be able to force the quality code, but it’s there for a reason. Getting rid of the long delay is your better solution.
Also, there may be some way to download and cache the images when the user first logs on. How fast is your network? How large are those images?
This might be a good time (for me) to inquire about images downloading prior to the window opening to show a “nice” hourglass. My guess is that it isn’t currently possible (don’t know what to download until after you de-serialize the window), but that it could be supported by FPMI keeping track somewhere else. I’m not sure if the concept extends to DB queries or anything else. It would certainly make window opening “feel” smoother.
All of the images are png, and the largest is 30kb. The network isn’t an issue with the tests I’ve been running, because I’m launching the GUI on the server PC. When I ran it on the client PCs a couple of weeks ago, I didn’t see a difference.
Humm…mind sending me a copy of the images and window backup? Doesn’t sound like it should take 17 seconds.
Ok, sorry it took me so long to jump in here.
Lets tackle the image problem first. The issue here is that when a window opens, the images are fetched from the server (if they’ve never been fetched before), and then they need to be resized to the appropriate size. This should be really quick. It shouldn’t take 17 seconds. Is the computer you’re running on from the 90s? It may be that the computer’s graphics card driver needs to be updated - it sounds like you have no 2D hardware acceleration.
As for the SQLTags problem, this also shouldn’t be noticeable. In fact, you really shouldn’t even see the unknown quality code unless your scan classes are set to leased. Please give us the specs of the client computer you’re running on, as well as the version of Java that the client is running on.
Thanks,
Just to update anyone that might be interested, the problem turned out to be the update base rate on my project settings. It was set very low (200ms), and SQL Server was just getting hammered. This was set in the dark ages before SQL Tags, and it never even occurred to me change it again later on. What is strange is that once the screens loaded, they ran fine, which is probably testimony to how lean your systems runs.
Its also a testament to your SQLServer 
It was handling over 600 queries / sec quite gracefully - eating up all your CPU, yes, but still going strong.
As an aside, we’ve just finished running the numbers on our official benchmarks, and even we were pleasantly suprised - stay tuned for the forthcoming whitepaper.