I think there is an opportunity for GS to look into some coding inefficiency. I just recently purchased the iMac 2017 with the fastest processor available (4.2 GHz Intel Core i7), 32mb of RAM and 1TB of SSD storage. GarageSale response time has improved to almost instantaneous with two exceptions. I think this might point out some potential coding issues that might be slowing down program response time, especially for those users with older computers.
As some background, I have been using GS for at over 4 years and have over 20,000 listings in the database. Running GS 7.0.7 (795) and macOS Sierra V10.12.6
1). After selecting groups of listings (typically 250-400) and then choosing the ‘Select All’ option in the ‘Preview Mode’ there is a significant pause. It is interesting that if you switch to the ‘Live’ mode, the ‘Select All’ option is instantaneous. Of course, to make listing changes to all the items selected, you must be in ‘Preview Mode’
2). Using the above selection and subsequently choosing to schedule the listings with GS scheduler, the duplicate previously listed item function and move to trash essentially uses all the resources of the computer (i.e. spinning wheel) and takes longer to complete considering the processing power of the computer. This is a major disappointment as I list 15,000+ items a month.
2a). Regarding #2, as reported about 18 months ago, there is no option when using the GS scheduler to specify the eBay account to use. We list in 4 eBay accounts, so if the listings are not in the default account, the verify function in the scheduler shows an error for every listing. This is not the case when listing groups without using the scheduler since there is a dropdown box to specify which eBay account is to be used.
Again, overall GS is working terrific. These two areas should be looked at in order to ensure the best possible experience for the user.
Here is a link to a work in progress build that should address the issues 1) and 2) from your original post. Please give it a try and let us know if it works any better:
Ilja - RE: Speed Issue Enhancement - The screen recording you requested was sent to you via Dropbox. In addition to showing the delay and excessive computer resources required in re-listing items (216), you can see there is no option to specify the eBay account associated with the listings. This is further depicted at the end of the video when the items are set up as an event in the scheduler when errors are displayed since the listings are associated with account ez-collectibles rather than the default account ez-creations.
Warren
Thanks again for the video. I assume you did the video with the special build I posted in this thread, didn’t you? (just making sure )
At my place, the process takes only a few seconds, so I’m clueless where the time difference comes from. Can you please follow the instructions to gather a little diagnostic data so I can see where GarageSale spends its time?
Launch GarageSale if you don’t have it already running
Open the Activity Monitor application (under /Application/Utilities)
Select GarageSale from the list of running applications in Activity Monitor
Chose “View” menu > “Run Spindump” (Activity Monitor will probably ask you for an admin password at this point)
Restart the process of creating events from a bunch of already started listings.
Wait until GarageSale is finished, return to Activity Monitor, save the spin dump log, and send it to me
Thanks, but unfortunately the command only records the first 10 second of activity, and it seems there was no beachball in this timeframe within GarageSale.
Can you please run through the instructions another time, but switch places of items #4 and #5: Force the beachball in GS first, than invoke the spindump command. Hopefully the beach balling is long enough to be recorded…
I sent you a new spindump2 file via Dropbox. Hopefully, it will contain the executable code that is responsible for the issue. The Run Spindump option seems to only record for a few seconds.
Here is a new build that optimises a few things, but nothing dramatic - so I would be surprised if you see any performance difference. Nevertheless, please give it a try and let me know if you notice anything.
There “appears” to be some improvement with the most recent build. After reboot and GS as the only program running, the time it takes for the “New Event from Selected Listings” option to Duplicate and Move to Trash 416 listings was 36 seconds. It does use all the CPU resources (spinning beach ball). All things considered this is an acceptable delay.
Thanks for trying this new build. 36 seconds doesn’t sound too bad. Maybe I can optimise of few more corners once I see more than 10 seconds of diagnostic data. Unfortunately, that’s not possible from the Activity monitor utility. But you can do it with the Terminal utility like this (once you find the time):
Make sure you have re-named to most recent build I sent you to ‘GarageSale’ and not ‘GarageSale 2’ or something similar
Launch GarageSale if you don’t have it already running, or restart if you just renamed it
Open the Terminal utility (under /Application/Utilities)
paste the following line into the Terminal window and press return:
I believe I was able to optimise of few more seconds out of the process in the latests betas. Also, the command for creating new event now has an accounts submenu.
Please give that version a try and see how it works for you:
Thanks. The submenu works fine. I failed to mention what I believe is a display issue in this same area. I scheduled 397 listings all of which required duplication and movement to the deleted folder. The preview mode display panel then shows 794 items; 397 new ones and the 397 that were moved to the Deleted folder. Obviously, this is confusing. I believe all you need to do to correct this is refresh the preview mode window after creating the event,
)