Re: [Gramps-devel] Virtual age columns

[<ben...@ug...>]

Douglas,

great that it has no impact on performance. I did not understand 
however if with
old columns you mean the official 2.2.6 branch, or your changed code without
showing the age columns. The way I understand the view, the database is
completely scanned to make the sorting on name. If I understand correctly your
field is only calculated when it has to be shown on screen, but perhaps it
calculated even if not shown? Anyway, you should compare 2.2.6 with your
changes in case you didn't do that now.

I do think that if you add extra fields to the person view, you should 
make sure
these fields also are available in the Person Dialog. It would be strange I
think to see more information in the list view than in the detailed dialog
view.

You say you don't change tables, I suppose you mean database tables. So how do
you then calculate the probable age of people of who birth/death is 
unknown? Or
did you not tackle that yet?

Benny

Quoting "Douglas S. Blank" <db...@cs...>:

> ben...@ug... said:
>
>> Doug,
>>
>> Although extra columns would fit the needs you put forward, there are
>> still some problems.
>>
>> I think you must understand it is extremely unlikely that much extra
>> columns are
>> added, let alone columns that need processing time to calculate.
>> Performance of
>> the people view is very important.
>
> Ok, fair enough. So the main concern is how it effects the people view,
> and I hadn't looked at the speed impact at all. I have now performed tests
> on these new columns with a database of over 100,000 (of real data). Two
> places one would notice time differences would be when expanding all nodes
> in the people view, and when scrolling.
>
> I did a variety of experiments, with and without the new columns. I timed
> (with just my watch, nothing fancy) expanding and collapsing all rows. I
> found the following. Time to:
>
> expand default old columns: 9 seconds
> expand all old columns    : 8 seconds
> collapse columns          : 7 seconds
> expand just age at death  : 6 seconds
> expand new and old cols   : 8 seconds
> expand just new columns   : 7 seconds
>
> So, the computation on these new columns does not add to the time to
> expand the columns. It takes between 6 seconds and 9 seconds, regardless
> of what one is showing or not showing.
>
> Next, I tested scrolling from top to bottom of the 100,000 database with
> the view fully expanded. I found that the more columns one shows, the more
> sluggish the scrolling (as one might expect). However, this is true with
> all of the standard columns. The proposed columns did not slow the
> scrolling down any more than any other column (although gender might be
> slightly faster to render, and spouse, birth, and death dates might be
> slightly slower). Of course, this is under the user's control, so they can
> adjust as they see fit.
>
> I think that these data points suggests that there is no inherent reason
> why we might want to prevent the user from being able to display this data
> in the people view. I have no desire to change the tables. I leave the
> filters for later, but I do agree with Benny that these will be useful.
>
> Given that these don't have significant negative impact, require very
> little code (low maintenance), and could be quite useful to people, this
> leaves some of my original questions:
>
> 1) Don and Richard both indicated that the model/view code may change
> soon. These two columns are pretty simple code, so shouldn't have a large
> code impact. Should we add them to 2.2 and/or
> 2.3, or wait till the new model/view is implemented?
>
> 2) The "Age on Date" requires a date. I have an idea on this that has
> little impact on code or interface.
>
> 3) Are there other age-related values that you would like to see in the
> person view, or in other places?
>
> The next step, I'll provide a patch and you can try this out.
>
> As always, thanks for any and all feedback,
>
> -Doug
>
>> Storing a calculated value in a database is also highly unlikely. It
>> could cause
>> disaster for the saving time of a person record, as well as problems
> when > the
>> algorithm is improved after an upgrade, ...
>>
>> A filter has the disadvantage as you say that you do not see why it
>> returns the
>> data you request. Like if you do name search Jon, and you get Jan
>> returned. You
>> can deduce that Jan has an alternate name Jon, but you do not see it.
>> This is a general issue with filters, a general solution for this
> problem > not
>> requiring the addition of columns would be most welcome.
>>
>> Benny
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.