The more data you get in a single account, the more speed issues there seem to be. I have found a single statement which contributes greatly to the overall speed decrease; however, I cannot find an alternative to it. The problem is the command:
on line 410 in TransactionsFrame.java. This command can take upwards of a few seconds to execute, on an older machine.
To all the developers out there: what can I use to do the same thing, that does not take as long? The objective of this command is to scroll the list of transactions all the way to the bottom; it should not take this long! I have tried all of the obvious ones, and some of the less obvious ones, and either a) they don't do what I need or b) they are just as slow.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For general information: version 1.9 includes a drastic speed-up to the transactions. I think that this should now be sufficient for even the slowest computers which can actually run Java programs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know what's excatly makes application look "slow", but i'll try:
Columns in Every list changing their width when window is resized. Looks like it takes a lot of time to calculate this action.
Can it be done something like columns changing their width only when something like "onResizeFinished" event appears ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where is this happening? (I.e., which screen? Transactions? My Accounts? My Budget? Other?). Which version are you using? In 2.1.x I have added new drawing routines, which make the display look much nicer. I don't notice any problems with speed (on a 3 year old Powerbook), but if you have hardware much older than that, you may... give me more details, and I will see what I can do.
Cheers
--Wyatt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nop, it's not Hardware : PB G4 1.67GHz, 2Gb RAM.
Buddi Version: 2.1.4
Of course it may be normal, but it looks slowish. Repainting of forms look very slow and painful.
For example is main form( My Accounts). Resizing takes alot of CPU time.
Pic: http://www.samofals.com/tmp/buddi.png
For Example if I compare resizing of CyberDuck main window - it's repainted instantly. There is no feel of any hard CPU usage.
( Both/Buddi & CyberDuck/ windows has something like NSTableView and dynamic column resizing)
P.S. Also a _small and straight forward Step-By-Step guide_ in developers section how to compile Buddi from source would be nice :) I downloaded Eclipse & EMF, tried to create project "Java project from existing ANT buildfile" and got about 2583 errors :) I think it's usual with Java at the beginning. So " If you load the unpacked source into a new Eclipse project, everything should work just fine." is not enough for me :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ahh, I see what you mean. That is to a certain extent a result of using Swing (I find that Swing response speeds are quite good for many things, but resizing could use improvement, especially on a Mac). I think this is in part due to the fancy resizing methods used on a Mac, as well as the generally slow Java implementation (I have compared Java speed on the Mac to similar machines running Windows, and the Mac version is approximately 2 - 3 times slower). I could probably try some optimizations to the GUI routines, but I currently have more pressing needs, and unfortunately optimizations tend to go on the back burner. I am hopeful that the recent GPL'ing of Java, gcj (with the addition of GNU Classpath / OSS Java libraries) will eventually allow us to compile Java (and Swing) natively - this will probably help see an increase in speed.
Of course, if you are able to optimize the GUI at all, please do so and send me a patch - I would be more than happy to include it!
That, of course, brings me to your second question - how to compile Buddi 8-) Honestly, I think that my 'Get Eclipse and EMF, and it will work' comment is pretty accurate: I have compiled Buddi on quite a few different machines and OS's, and each one works without much (if any) tweaking, assuming that EMF is set up properly. As well, there was a student project at NCSU in which multiple (my count is about 15) students worked on some part ob Buddi which was lacking - they all were able to compile with (from what I can tell) only minor difficulties. A resource which I created for them which is not currently linked to from the main page is the EMF tutorial, at http://buddi.sourceforge.net/en/emf.php. While focused towards the Data Model side of the house, it is very helpful for seeing what you need to download.
In addition to my EMF tutorial, you can look at the NCSU discussion board. Some of the earlier comments were in regards to compiling.
If you are getting thousands of errors, my guess is that you don't have EMF properly set up. If you can copy and paste the first few (~10) error messages to this thread, I can see if they look familiar and perhaps point you in the correct direction.
Finally, what method you used to obtain the source (either SVN or tar.gz) can be helpful. In general, I recommend using SVN, unless you have a strong reason not to.
Hope this helps; please let me know of any further questions, and I will do what I can to help.
Happy Holidays!
--Wyatt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ough, it's actually kind'a tricky to get it running ( I downloaded Eclipse for the first time yesterday)
Eclipse + Argo2Ecore plugin + EMF Install + net.sf.fjep.fatjar_0.1.0.zip + build.xml tweaking + (right-click on build.xml -> Run As -> Ant Build)
Looks like my guess was wrong.
org.homeunix.drummer.view.ListPanelLayout.java:62 ( I tried AUTO_RESIZE_OFF, columns are not resizing anymore ) and still "slowish" :(
Happy Holidays for You too!
P.S. Don't get too seriosly to my writings ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The more data you get in a single account, the more speed issues there seem to be. I have found a single statement which contributes greatly to the overall speed decrease; however, I cannot find an alternative to it. The problem is the command:
list.ensureIndexIsVisible(list.getModel().getSize() - 1);
on line 410 in TransactionsFrame.java. This command can take upwards of a few seconds to execute, on an older machine.
To all the developers out there: what can I use to do the same thing, that does not take as long? The objective of this command is to scroll the list of transactions all the way to the bottom; it should not take this long! I have tried all of the obvious ones, and some of the less obvious ones, and either a) they don't do what I need or b) they are just as slow.
Thanks
For general information: version 1.9 includes a drastic speed-up to the transactions. I think that this should now be sufficient for even the slowest computers which can actually run Java programs.
I don't know what's excatly makes application look "slow", but i'll try:
Columns in Every list changing their width when window is resized. Looks like it takes a lot of time to calculate this action.
Can it be done something like columns changing their width only when something like "onResizeFinished" event appears ?
Where is this happening? (I.e., which screen? Transactions? My Accounts? My Budget? Other?). Which version are you using? In 2.1.x I have added new drawing routines, which make the display look much nicer. I don't notice any problems with speed (on a 3 year old Powerbook), but if you have hardware much older than that, you may... give me more details, and I will see what I can do.
Cheers
--Wyatt
Thank You for answer!
Nop, it's not Hardware : PB G4 1.67GHz, 2Gb RAM.
Buddi Version: 2.1.4
Of course it may be normal, but it looks slowish. Repainting of forms look very slow and painful.
For example is main form( My Accounts). Resizing takes alot of CPU time.
Pic: http://www.samofals.com/tmp/buddi.png
For Example if I compare resizing of CyberDuck main window - it's repainted instantly. There is no feel of any hard CPU usage.
( Both/Buddi & CyberDuck/ windows has something like NSTableView and dynamic column resizing)
P.S. Also a _small and straight forward Step-By-Step guide_ in developers section how to compile Buddi from source would be nice :) I downloaded Eclipse & EMF, tried to create project "Java project from existing ANT buildfile" and got about 2583 errors :) I think it's usual with Java at the beginning. So " If you load the unpacked source into a new Eclipse project, everything should work just fine." is not enough for me :(
Ahh, I see what you mean. That is to a certain extent a result of using Swing (I find that Swing response speeds are quite good for many things, but resizing could use improvement, especially on a Mac). I think this is in part due to the fancy resizing methods used on a Mac, as well as the generally slow Java implementation (I have compared Java speed on the Mac to similar machines running Windows, and the Mac version is approximately 2 - 3 times slower). I could probably try some optimizations to the GUI routines, but I currently have more pressing needs, and unfortunately optimizations tend to go on the back burner. I am hopeful that the recent GPL'ing of Java, gcj (with the addition of GNU Classpath / OSS Java libraries) will eventually allow us to compile Java (and Swing) natively - this will probably help see an increase in speed.
Of course, if you are able to optimize the GUI at all, please do so and send me a patch - I would be more than happy to include it!
That, of course, brings me to your second question - how to compile Buddi 8-) Honestly, I think that my 'Get Eclipse and EMF, and it will work' comment is pretty accurate: I have compiled Buddi on quite a few different machines and OS's, and each one works without much (if any) tweaking, assuming that EMF is set up properly. As well, there was a student project at NCSU in which multiple (my count is about 15) students worked on some part ob Buddi which was lacking - they all were able to compile with (from what I can tell) only minor difficulties. A resource which I created for them which is not currently linked to from the main page is the EMF tutorial, at http://buddi.sourceforge.net/en/emf.php. While focused towards the Data Model side of the house, it is very helpful for seeing what you need to download.
In addition to my EMF tutorial, you can look at the NCSU discussion board. Some of the earlier comments were in regards to compiling.
If you are getting thousands of errors, my guess is that you don't have EMF properly set up. If you can copy and paste the first few (~10) error messages to this thread, I can see if they look familiar and perhaps point you in the correct direction.
Finally, what method you used to obtain the source (either SVN or tar.gz) can be helpful. In general, I recommend using SVN, unless you have a strong reason not to.
Hope this helps; please let me know of any further questions, and I will do what I can to help.
Happy Holidays!
--Wyatt
Ough, it's actually kind'a tricky to get it running ( I downloaded Eclipse for the first time yesterday)
Eclipse + Argo2Ecore plugin + EMF Install + net.sf.fjep.fatjar_0.1.0.zip + build.xml tweaking + (right-click on build.xml -> Run As -> Ant Build)
Looks like my guess was wrong.
org.homeunix.drummer.view.ListPanelLayout.java:62 ( I tried AUTO_RESIZE_OFF, columns are not resizing anymore ) and still "slowish" :(
Happy Holidays for You too!
P.S. Don't get too seriosly to my writings ;)