04.10.2012, 10:59
Now that it has been confirmed that no new major DFS versions will be forthcoming, I would like to turn the developers' attention to optimizations that will allow this fine piece of software to run faster (both improving overall responsivity and the speed of queries).
While users can already speed up DFS to some extent by turning off some features and caching final tables etc., things could certainly still be improved.
As an owner of a low-end Intel D525 CPU (which I chose for its minimal energy consumption), I admit that working with DFS can be mildly to extremely frustrating in some cases, especially as I am the maintainer of the third largest DFS database (after the Bundesliga and Premier League) which might still grow by 50% more if I added everything I could reasonably add. Yet even if I defragment the database at regular intervals the working speed is so slow that I am often disheartened at the prospect of making anything else than regular updates.
I also have had an international matches database in the works, but the eventual handling of more than 20,000 players (and that's just for European teams) is currently out of question unless steps are made to speed up the management screens, as outlined below.
The issue with DFS is simple: it tries to present a lot of information to the user at the same time and in the process makes dozens of queries which consume precious system resources. But things would be considerably sped up if the user was able to choose which information they want to see. For example, it is possible to turn off the timeline and W/D/L balance now (and indeed this is necessary for me to obtain any realistic working speed), but why not the topscorers list? Likewise, I don't always need to see the current number of apps/goals/yellow cards in the lineups, and being able to turn these off would eliminate another couple of queries. Finally, queries are often run unnecessarily, for example the lineups are refreshed even when the only thing added/changed is the number of spectators.
The team/player/referee management screens would benefit from some reworking too. For example, when you open the player management screen DFS runs several queries for each player so that the user can immediately see the number of leagues/teams/appearances/goals/last appearance date etc. for that player. It also caches all squads for all seasons in the current league for easy retrieval. Tremendous cuts in processing time could be made if all of this was optional.
Finally, DFS could use some more computed data caching within the databases, for example the number of apps/goals in each season to make the Steckbrief/Kader window display even faster etc. Of course it would increase the already bloated database files on disk, but caching information once when match data are changed is preferable to running the same queries over and over. Again, this would be optional and off by default, so that current user experience remains unchanged.
Now some of you might shrug and say "Why are you bothering us with this, buy a faster computer or live with it." Well, for some reasons I would rather have a low electric bill than a high-end CPU that is used sparingly at full power but devours enormous amounts of energy even when idle. But whatever my preferences, you should not turn your back on users with low-end hardware just because your CPU has twice the MHz. If DFS is optimized as suggested above, slow work would become fast, and fast work would become instantaneous. Everyone wins, really, and nobody is forced to change anything in their settings if they don't want to.
Hoping for an open discussion on the subject.
MfG
While users can already speed up DFS to some extent by turning off some features and caching final tables etc., things could certainly still be improved.
As an owner of a low-end Intel D525 CPU (which I chose for its minimal energy consumption), I admit that working with DFS can be mildly to extremely frustrating in some cases, especially as I am the maintainer of the third largest DFS database (after the Bundesliga and Premier League) which might still grow by 50% more if I added everything I could reasonably add. Yet even if I defragment the database at regular intervals the working speed is so slow that I am often disheartened at the prospect of making anything else than regular updates.
I also have had an international matches database in the works, but the eventual handling of more than 20,000 players (and that's just for European teams) is currently out of question unless steps are made to speed up the management screens, as outlined below.
The issue with DFS is simple: it tries to present a lot of information to the user at the same time and in the process makes dozens of queries which consume precious system resources. But things would be considerably sped up if the user was able to choose which information they want to see. For example, it is possible to turn off the timeline and W/D/L balance now (and indeed this is necessary for me to obtain any realistic working speed), but why not the topscorers list? Likewise, I don't always need to see the current number of apps/goals/yellow cards in the lineups, and being able to turn these off would eliminate another couple of queries. Finally, queries are often run unnecessarily, for example the lineups are refreshed even when the only thing added/changed is the number of spectators.
The team/player/referee management screens would benefit from some reworking too. For example, when you open the player management screen DFS runs several queries for each player so that the user can immediately see the number of leagues/teams/appearances/goals/last appearance date etc. for that player. It also caches all squads for all seasons in the current league for easy retrieval. Tremendous cuts in processing time could be made if all of this was optional.
Finally, DFS could use some more computed data caching within the databases, for example the number of apps/goals in each season to make the Steckbrief/Kader window display even faster etc. Of course it would increase the already bloated database files on disk, but caching information once when match data are changed is preferable to running the same queries over and over. Again, this would be optional and off by default, so that current user experience remains unchanged.
Now some of you might shrug and say "Why are you bothering us with this, buy a faster computer or live with it." Well, for some reasons I would rather have a low electric bill than a high-end CPU that is used sparingly at full power but devours enormous amounts of energy even when idle. But whatever my preferences, you should not turn your back on users with low-end hardware just because your CPU has twice the MHz. If DFS is optimized as suggested above, slow work would become fast, and fast work would become instantaneous. Everyone wins, really, and nobody is forced to change anything in their settings if they don't want to.
Hoping for an open discussion on the subject.
MfG
