I’m just experimenting with EagleFiler. I have installed 1.5.6 and set a library in a Dropbox folder (as I’d like the filed files to be accessible to my other computer too).
When starting EagleFiler it takes an eternity to start. I haven’t used a wall clock to time it, but I’d definitely say it’s close to 1 minute.
My library currently has 15 records.
When switching to EagleFiler I’m noticing the processor going up to 60%-80%.
It’s difficult to explain a slowness feeling, but playing with EagleFiler gives me the feeling of an unresponsive application.
Are there any tricks to do to make things better? I’ve looked through the forum’s history and I couldn’t find anything very relevant. So it’s either a very subjective perspective on my side or some wrong expectations.
What kind of Mac do you have? Which version of Mac OS X? Are there other applications running at the same time? Is there anything going on in the Activity window? Just trying to get a general idea here.
It would be helpful if you could measure what EagleFiler is doing. Open the Activity Monitor program and select EagleFiler in the list. Just before you do something that will make it slow, choose Sample Process from the View menu. Please do this a few times, then save the windows to files and send them to me.
I’ve basically closed all apps that could consume resources.
As a comparison I’ve imported the same 15 items into Together and it remained snappy. I’m not sure that’s any indication, but I wanted to understand if:
a) it is something specific to the 15 items
b) it is something specific to having the library in the Dropbox folder
I don’t think so. I know it can be slow to launch the first time on Lion (though a minute is longer than I would expect), but it should be fast with just 15 records. That’s why I’d like to see some sample logs.
Thanks for sending the samples. Unfortunately, this is still a mystery because they show that EagleFiler is almost entirely idle. It doesn’t seem to be doing much processing of its own, nor is it waiting on the disk or network.
When you said that the processor is “going up to 60%-80%,” how long does that last? Could you get a sample during that time?
I’ve tried to take the samples at those peak times. I could try to record a screencast to see what I mean about slowness, but I’m not sure how useful that would be.
Here are a couple of examples:
just try to resize the window. Does it behave like all other apps you have around?
Place the Read and Quick view buttons in your toolbar.
Make sure there’s no record selected.
Select a record => watch when the Read button is enabled. Watch when the Quick view button is enabled
As I said maybe it’s just an impression and the core app works ok–I still maintain my opinion that the start time is awful–and it is these UI facts that make me feel there’s something wrong with it.
That’s not necessary. I believe you that you’re seeing slowness; what I’m interested in is finding the cause.
Some apps that I have are super-smooth when resizing, e.g. TextEdit. EagleFiler seems around the same speed as Mail; reasonably smooth, the animation isn’t jumpy, but the corner of the window lags a bit behind the pointer. It’s much more smooth than, say, OmniFocus or Xcode.
I see that there’s a fraction of a second delay between when Read is enabled and when Quick Look is enabled. Are you seeing something different?
The slow launch time is a known issue that I’m working on. I’m more concerned about the other stuff. How are you finding the typing speed, scrolling speed, and searching speed?
I could see why TextEdit could be snappier, but in my case even OmniFocus is crazily faster than EagleFiler. I’m not using Mail or Xcode to compare with these. But as I’ve mentioned in my email I do have some Java-based IDEs (IntelliJ, PyCharm) which are both behaving much better in terms of UI responsiveness.
Same here.
Once again, I don’t want to sound nitpicking but this behavior can actually contribute to perceiving EagleFiler as been slow. I do have the feeling of old Java applications that were performing both their functionality and UI work in the same thread.
I appreciate the constructive feedback. I’m not sure why we’re seeing somewhat different results (e.g. the relative speed of OmniFocus). Improving the general UI snappiness is something that I’m working on, so it’s not necessary to report the individual little issues at this time. However, if you notice any larger-scale performance issues (aside from launching, which I know about), please do e-mail me a report with some sample logs, as there may be something weird going on or there may be a targeted fix/optimization that can be applied.