Re: Is FSEvents more efficient than polling?
Re: Is FSEvents more efficient than polling?
- Subject: Re: Is FSEvents more efficient than polling?
- From: Steven Degutis <email@hidden>
- Date: Sun, 28 Apr 2013 13:16:53 -0500
Let me give a little more context. The app is a Clojure
test-auto-runner[1], that spins up the JVM and watches files to reload
and re-run the tests for[2].
I'm concerned that running this auto-runner on my laptop is killing
the SSD and battery quicker. Especially because these rMBPs don't have
easily-replaceable parts, so once it's dead, it's probably dead for
good.
If it is a real concern, I have a plan. I previously wrote a little
utility before called fswatch[3] that watches for changes and runs a
script. I can just alter this stay open until you kill it, and print
the changed files to stdout at every fs-event. Then I'd just open this
process in Clojure and watch its stdout for files and reload when I
see them.
[1] https://github.com/slagyr/fresh/blob/master/src/fresh/core.clj
[2] See the usage section in the URL "x-dictionary:preposition"
[3] https://github.com/crh/fswatch
On Sun, Apr 28, 2013 at 12:52 PM, Michael Starke
<email@hidden> wrote:
> An educated guess would be that polling should be less efficient as the event based FSEvents.
> Any reason you do not want to tap into the FSEvents API?
>
> You concerns about weakening is nothing I would consider, as you're talking about reading, which should be considered harmless (in the physical sense, not the performance point of view)
>
> -Michael
>
> On 28.04.2013, at 19:43, Steven Degutis <email@hidden> wrote:
>
>> There is a library I'm using that is reading a list of files every 0.5
>> seconds and watching for the last-modified attribute to change.
>>
>> Is this less efficient than using FSEvents? If so, how? For example, will
>> it weak down the HDD or SSD faster? Run the battery of my laptop out
>> sooner? Some other way?
>>
>> Thanks.
>>
>> -Steven
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> ___m i c h a e l s t a r k e____
> geschäftsführer
> HicknHack Software GmbH
> www.hicknhack-software.com
>
> ___k o n t a k t____
> +49 (170) 3686136
> email@hidden
>
> ___H i c k n H a c k S o f t w a r e G m b H____
> geschäftsführer - maik lathan | andreas reischuck | michael starke
> bayreuther straße 32
> 01187 dresden
> amtsgericht dresden HRB 30351
> sitz - dresden
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden