Archiving old transations

[Bob Brush 3]

Probably not a necessary post, but I think opening GiMP is like booting
another OS, it has to be the most frustrating thing, especially when
doing something little..  Amarok is slow too.. I changed to gnumeric and
abiword because they seem to load faster than open office..  but just
now I see that open office is libre office and is killing abiword in
startup time, wonder what they changed?  But the absolute slowest is
Shotwell, which I discovered is mostly my fault, but can take in the
order of 20 minutes to start with no real indication things are working
other than an absolute thrashing of the hard drives..  Basically they
report it was never designed to handle that much information and people
that do are "brave" (scary) so in my use where everything is slow..
GnuCash is middle of the pack.. It seems like programs that have
database back ends (or should) are just in a different class altogether
than little gui things that do stuff, which pushes people to leave them
on all the time.   Maybe we need to put gnucash in the cloud, oh wait, I
hate that...

On Fri, 2013-06-21 at 07:13 -0400, Jonathan Kamens wrote:

> On 06/21/2013 03:54 AM, Colin Law wrote:
> > How long does it take to load the file with no tabs open?  Time for
> > how long it shows "loading user data" on the startup screen (with no
> > tabs open).
> It appears that if I had not already archived many years of transactions 
> because of the start-up speed issue, it would take ~10 seconds to load 
> the user data every time I started the app. And that's just loading the 
> user data -- it's around another eight seconds to load all the reports 
> and do the other non-data initialization.
> 
> By way of comparison, LibreOffice Writer takes four seconds from when I 
> launch it until when I have a window ready for me to type in. Firefox 
> takes even less time than that. GIMP takes less than eight seconds when 
> I start it up cold, and less than four seconds when I close it and 
> immediately open it again. Picasa, which is managing far more data than 
> GnuCash is for me, starts up in 12 seconds total, and that's including a 
> speed hit from running inside VirtualBox.
> 
> If supporting archiving old transactions is such an albatross, then I 
> suppose another option for improving startup time would be to figure out 
> how to make it take less time to do the non-user-data initialization. 
> For example, I suspect that GIMP does some sort of caching of plugin 
> initialization so that plugins can be initialized faster after the first 
> time, and that's why it starts up so much more quickly the second time 
> than the first.
> > Is that 21 MB of compressed xml?
> No, uncompressed, because I transfer it regularly between machines with 
> rsync, whose diff algorithm works much better on an uncompressed file. 
> Loading a compressed file takes about the same time as an uncompressed 
> file; as far as I can tell, it's the processing, not the disk I/O, that 
> causes most of the delay.
> > They are under
> > no obligation to do anything for anyone.
> I am not talking about obligation. As I've already said, I assume that 
> most people who maintain software actually care about giving their users 
> the features they want and need, and I believe that this feature falls 
> into that category.
> 
> Of course, there are exceptions to that rule. The maintainters of GIMP 
> have written off a (large) class of users and have made it clear and 
> explicit on numerous occasions that they have no intention of putting 
> any effort into making their app more hospitable to those users. I think 
> that's an unwise thing for them to do, but it's their right, and at 
> least they're up-front about it.
> 
> That's not what has happened here. No one has ever said, as far as I can 
> tell, "We don't think the kind of users who care about GnuCash taking 
> too long to start up is our target demographic, so we're not going to do 
> anything to help them." Rather, what has been said is, "Yeah, that's a 
> problem, and we're working on a fix" (and then no fix has arrived), or, 
> "Yeah, that's a problem, but no one is actually working on fixing it," 
> or, "Shut up and stop complaining" (mostly by non-developers).
> > Telling them that they are
> > rude and patronising is not likely to encourage them to help you.
> > More likely the contrary in fact.
> I was polite about it for many, many years. And as you just pointed out, 
> you're not a GnuCash developer, so apparently I /didn't/ tell the 
> developers that they are being rude and patronizing.
> > I think the reason that it has not been addressed is that most do not
> > see it as a problem that needs to be fixed.
> Several GnuCash maintainers over the years have acknowledged the problem 
> and indicated at least a theoretical desire to solve it, so I think you 
> are wrong about that, and I think that since you are not a developer, 
> you should perhaps stop trying to speak for them.
> 
> There are features in my Thunderbird add-ons that "most" users do not 
> use, but they benefit enough of my users that I was willing to put many 
> hours of work into implementing and maintaining of them.
> > I certainly do not want
> > to archive old data out of my main file.  I like to have access to my
> > complete history so I can easily search for old data.  I often find
> > myself, for example, searching to find when I bought something, and
> > love that fact that I have 15 years historical data easily available.
> The fact that there are some users who do not wish to archive their old 
> transactions has little to no bearing on whether there are enough users 
> who do to justify making it possible.
> 
> The facts that three different developers over the years have 
> implemented solutions to this problem, and that many people have asked 
> about it over the years, would seem to imply that there are a 
> significant number of users who want to be able to do this.
> 
>    jik
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20130621/47148500/attachment.sig>