From: Douglas S. B. <db...@cs...> - 2007-02-15 00:57:48
|
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 |