How many objects are there on a big component?

Author: michael.taylor@uniface.com (Mike Taylor)

I have a question for the Uniface community - how many objects, or UDOs (Uniface development objects) in v10 speak, are on your largest components? An object is basically anything painted - entities (not repetitions), fields (any widget type), labels, line/area frames, break frames, headers, footers or split bars.  A little background to the question - We have been optimizing of the new component editor in version 10 so we can be confident, that when applications are migrated, it performs well . In v10 there is no technical limit to the number of objects that can be defined on a component however, how many objects should we make sure we are optimized for? A good measure of this would be the maximum number currently being used in your applications. Many thanks for your help Mike.

9 Comments

  1. Hi Mike, think it would be a good approach if you can provide a nice little tool for the community investigating the repostory to find the figures you are shooting for. This open-source code can easily compiled by anyone interested and if there is some log of the results, it can be mailed directly to you. Assume the basics can be a count of UXGROUP and UXFIELD occurences per component, so using UFORM as a lead and individual selectdb counts  and keeping the maximum would do the job. A much faster way could be a selectdb with max and a group by FORMNAME or something similar.   Greetings from stormy Frankfurt/Germany, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  2. Hi Mike, the largest component I've met in my experience with Uniface is dedicated to collections renewal in a male / female clothing shop; it was so large we called it "mappone", meaning in italian "a big big big map". The business complexity is coming from articles with size/colors attributes, the complexity within the supply chain and a pre-requisite from customer to exactly reproduce screens from another application used before to avoid users re-training. The technical complexity was related to software development policies forcing to include all business rules related to each component into the component itself (strictly in C/S mode!). This component is globally including 61 entities; 8 entities are directly including fields or other layout objects (labels, buttons, ...) on paint tableau with a total of about 400 painted objects (220 fields and 180 other layout objects, mainly labels). The compiled size for this component in U8.4 was a little less than 500kB without compression while today in U9.5 is 93kB compressed. It is in production since 2005... :-) :-) :-) Hope it helps... Gianni P.S. I fully support the idea from Uli...a nice and up2date tool to analyze repository usage would be welcomed...


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  3. Hi, We are currently not looking for an exact number, just rough estimates. We have made the assumption, which seems to be held up by Gianni, that components containing 250(ish) objects would be some of the largest ones out there. To make sure that v10 is good we are optimizing it for 150, expecting it to perform with 700 and for it to be usable with 1300. Regards, Mike


    Author: Mike Taylor (michael.taylor@uniface.com)
  4. Hi Mike, there are not so many experts like Gianni who know where they have to look to collect the information you were asking for. Many do not know all the internals of their application by heart if it comes to the component with "most LOC", "most markers" , "most code labels, ..." As the truth is in the repository, a little form can collect the data you want even for customers which can not explore FORMPICs on their own. Think this will boost your sample size and gives some more realistic picture what's going on in the outside world.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. Hi Mike, I've tried to count the objects. It's very hard to count labels, area frames etc, but I started to count from UXGROUP and UXFIELD (after cleanup, of course). Here are some interesting information: Total number of components: 3704 (most of them are forms and services) The top number of entities: 175 (service component) There are some reports with >60 entities painted. Forms uses much less entities. The top number of fields: 363 (report component) As for form component, the highest number of fields is 223, but most of them are hidden to user. Common form with all fields visible has 186 fields painted. Overall (entities and fields), the highest is: 427 (report component) As for form components, it's 237 (entities+fields only!), but real form has 203 entities and fields. Most of the form has several area frames/lines. But just up to 10 objects. Most of the visible fields has associated label, so we have to double the field count! All in all... if I count only form components: tricky form: 14 entities + 223 fields + cca 50 labels = 287 objects. (most of the fields are hidden) real form 1: 28 entities + 169 fields + cca 169 labels/area frames/lines = 366 objects real form 2: 17 entities + 186 fields + cca 186 labels/area frames/lines = 389 objects real form 3: 26 entities + 150 fields + cca 150 labels/area frames/lines = 326 objects Those 3 real forms are the forms, which are used by our customers on every day basis. Kind regards, Zdeněk Socha


    Author: sochaz (zdenek.socha@fullsys.cz)
  6. Mike Taylor said Hi, We are currently not looking for an exact number, just rough estimates. We have made the assumption, which seems to be held up by Gianni, that components containing 250(ish) objects would be some of the largest ones out there. To make sure that v10 is good we are optimizing it for 150, expecting it to perform with 700 and for it to be usable with 1300. Regards, Mike

    According to my previous post... I think that 150 is too low. :-) It might be a good idea to optimize it for (at least) 200 or even 250 objects? It depends, on what you count as an object. If only painted objects or even not painted ones (many fields in entities are accessed from proc code but not visible to the end user). Zdeněk


    Author: sochaz (zdenek.socha@fullsys.cz)
  7. Here is some hint for the SQL Workbench (GOLD-W) to be used with $IDF as a path pointing to SOLID: select count(*) AA, UFORM from uxfield group by UFORM order by AA desc So if we run the above SQL script against uxgroup as well to get the entties Headers, Trailers and Breakframes, add the maximum counts of both (the worst case) and multiply it by 2 (As a rule of the thumb we assume one label per field)we may get some estimate To get the real numer of labels, area frames etc., one has to analyse the formpic which is a bit harder to do, takes a lot longer, but is possible as well.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  8. Can anyone top 825? Smile


    Author: diseli (daniel.iseli@uniface.com)
  9. Hi Mike, We have one component with 1001 fields. This form only has 10 entities, a few area frames and no labels. This is by far our biggest example, the next one has "only" 600 fields. However, the average number of fields per component is only around 40. Our components have between 1 and a 93 entities, with the average being 10 entities per component. We don't have many labels, as we use boilerplate fields as field labels. I guess most forms only have two or three area frames, and no lines. In total, we have over 11,500 components. Regards, Mark


    Author: Mark Rennison (mark.rennison@tribalgroup.com)