Half second pause before results show up

[ClimbsRocks]

This is an awesome script, and I use it all the time!

One things I've noticed is that there's a several hundred millisecond delay between when I finish typing in my search query, and when results show up. It's totally livable, but I thought I'd check in and ask about it in case you knew the cause off-hand.

It appears to get longer if I have a bunch of tabs open, so it might just be the limits of processing power.

I don't know much Ruby, but that hasn't stopped me from hacking on Ruby scripts in the past. If you don't have time to investigate but can point me to where it might be worthwhile to look, I'm happy to spend a bit of time checking it out myself.

Thanks again for the awesome tool!

[stuartcryan]

Howdy Preston,
I have noticed this as well and this is something that I want to see if I can optimise any further. I did not write the section of code that did that, it was a fork from another project. However I have now been getting my hands into Ruby a little bit more and would like to see if there is any refactoring that could be done to speed it up further.

Unfortunately I think that it might just be processing power and the true time it takes, but thank you for raising it. I will have a squiz and see what I can find, when I find the right files I will point you to them so you can have a look too.
Cheers,
Stuart

[ClimbsRocks]

Awesome, thanks @stuartcryan!

[stuartcryan]

Just to let you know I haven't forgotten this... I have been doing some testing but thus far nothing has proven any faster. :(

[ClimbsRocks]

Thanks! I was actually just thinking of this yesterday. It's noticeably
slower when I'm running a machine learning algorithm across all my cores.
That makes me wonder if either the regex is performing some inefficient
loops, or if we've introduced some unexpected time complexity somewhere.

Thanks for diving into this! I use this package constantly, and am really
glad you've built it.
On Mar 25, 2016 7:49 PM, "Stuart Ryan" [email protected] wrote:

Just to let you know I haven't forgotten this... I have been doing some
testing but thus far nothing has proven any faster. :(

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#10 (comment)

[stuartcryan]

Howdy,
Based on what you have said the regex could very well be the delay.

I have stripped out a plethora of it. Can you please give this version a try https://dl.dropboxusercontent.com/u/9093155/Rapid%20Browser%20Tabs_1.2_beta1.alfredworkflow and let me know how you go.
Cheers,
Stuart

[stuartcryan]

All righty... it looks like it isn't the regex. I did some time tests, the majority of the script takes (under ideal circumstances) ~200ms to run.

I ran some timing tests and the applescript (outside of any ruby) getting the tabs from Chrome takes 530+ms just to run on its own, so it seems like this is the biggest time sink.

If you put the following into a file named test.osascript and then run in terminal:
time osascript osatest.osascript --takeyourtime

You will see that result.

 set _output to ""

script V
    property _window_index : missing value
    property _tab_count : missing value
    property _tab_index : missing value
    property _output : missing value
    property _window : missing value
    property _tab : missing value
end script

tell application "Google Chrome"
    set V's _window_index to 1

    repeat with _window in windows
        try
            set _tab_count to (count of tabs in _window)
            set V's _tab_index to 1
            repeat with _tab in tabs of _window
                set V's _output to V's _output & "Google Chrome:" & (V's _window_index as string) & ":" & (V's _tab_index as string) & "
" & URL of _tab & "
" & title of _tab & "
"

                set V's _tab_index to (V's _tab_index) + 1
            end repeat
        end try
        set V's _window_index to (V's _window_index) + 1
    end repeat

end tell

V's _output

Now... there is a way to get around this, but I am loathed to suggest it and that would be to somehow prime what we are looking for, kick off a background process to get the results, cache them on disk and then if the file is less than say 15 seconds old use the cache.

However, this would come with its own inherent problems. I would also not opt to do a cache that refreshes periodically as that would simply waste CPU cycles.

Let me have a think, and see if there is any pleasant way I can come up with doing this that balances up to date information with speed.

[ClimbsRocks]

fantastic sleuthing!

i'll also spend a bit of time thinking through ways around this. i wonder if there's just a more efficient way of querying the tab list from chrome directly- 530ms just to get the list of tabs seems a bit absurd. i wonder if it first has to create some kind of connection to chrome (like a db connection) before it can make the query.

i've never messed around with this, so i'm just wildly conjecturing at this point! i'll try to do a little research- saving that half second would make all this flow much more naturally, and i use this all day long.

[littke]

Did any of you come up with a solution here? I'd be curious to see if there was a way around this too. Thanks for a great workflow!