Hi. I've mentioned this in the past, but I'd like to bring it up again, because it is still just as annoying. The Diigolet in Opera has a dropdown that automatically appears as you type in tags. Could we get a user option to disable this? It is FAR TOO SLOW. On this 1.7 GHz machine, once I'm done typing all my tags, it takes upwards of 60 to 120 seconds for the dropdown to finish thrashing my CPU, and only then can I properly submit my bookmark.
Not to mention the fact that it sometimes persists, leaving a visual artifact even after I submit the bookmark and the diigolet popup closes, and even after I click to hide the bookmarklet bar.
I never use this feature, so it is more than a little annoying for me to deal with. I beg of you, let us turn it off. :(
joel wrote: > Did it happen on FF or IE? We will try to reproduce the problem on Opera first to see whether we can solve it.
Thank you for your attention to the issue, joel. It is appreciated.
I don't use Diigo at all under IE, and in Firefox, I use the extension. So it would only be an issue for me under Opera. I don't suspect you would be able to easily reproduce it, because the particular machine in question has lower hardware specs, and is known to really crawl under even moderate loads.
I hope it's as easy as commenting out a function call or two, and then having an alternate version of the bookmarklet available for use. Hopefully this is not seen as a border case of only a few users that doesn't deserve attention. :(
If the bookmarklet were static code, I'd just change it myself, but my understanding is that it runs remotely and/or updates itself as new versions are published.
> > I don't use Diigo at all under IE, and in Firefox, I use the extension. So it would only be an issue for me under Opera. I don't suspect you would be able to easily reproduce it, because the particular machine in question has lower hardware specs, and is known to really crawl under even moderate loads. =======> Sorry, we can't reproduce it even on a 1.7G CPU PC. Could you change your password to a temp one and give it to joel 【at】 diigo dot com to help us reproduce it? If we still can't reproduce it, we will do a special version for you.
> If the bookmarklet were static code, I'd just change it myself, but my understanding is that it runs remotely and/or updates itself as new versions are published. =======> It's not static code.
joel wrote: > We reproduced the problem !!. It was caused by several reasons. > 1) The tagset is big. > 2) We developed and tested the diigolet on a relatively faster computer, so didn't notice the speed problem > 3) The most important reason is that One function in a Javascript library we use is slow. > > We hand crafted that function and tested it again, it is faster than before. You can try the new version 20070722150447 ( Mouse over to the blank space besides user name in diigolet, you can see the version number). If the version number is not right, please clear the cache and try it again. > > Tell us whether this solution solve your problem.
Well, I am happy to report that it seems to be working well. :) Praise be to God! The speed on this slow machine is acceptable, and I don't have that long wait or delay or anything. I can even actually click outside to make the dropdown disappear and not leave an artifact.
Good work, and thank you for your prompt attention and significant effort regarding this issue.
My tags block is automatically collapsed when I load my page--is that a setting somehwre maybe?
Joel Bennett wrote: > Yeah, I avoid your page too. > > Err, I mean ... it's slow for me too. Takes 16s just to download and over 10s on a refresh .... but around 20 seconds to actually finish struggling with the javascript enough to let me scroll with the mousewheel ;-) > > You want to see something REALLY annoying? In Firefox, open Pistos' user page, and try to scroll by clicking on the scrollbar gripper and dragging it. > > It must be the tags block, however -- because I (only? ha!) have about 1200, and it takes substantially less time to load, and the scrolling is much more responsive. Maybe it would be better to start that block collapsed, and load the data on demand when users click to open it... > > Incidentally --- try collapsing the Tags block, and then try again to scroll with the scrollbar -- much better, eh?
Ellen H. wrote: > My tags block is automatically collapsed when I load my page--is that a setting somehwre maybe?
Mine starts collapsed too, but I believe it is still vomitting all the HTML data up through the HTTP socket on the initial page hit, and merely keeping it hidden until you uncollapse it.
Pistos Christou wrote: > Ellen H. wrote: > > My tags block is automatically collapsed when I load my page--is that a setting somewhere maybe? > > Mine starts collapsed too, but I believe it is still vomitting all the HTML data up through the HTTP socket on the initial page hit, and merely keeping it hidden until you uncollapse it.
Download Speed: 5872 kbps (734 KB/sec transfer rate)
I don't think the speed of my net connection is an issue. The bottom line is it is trying to do a lot of work, and I would prefer to be able to have some options to make it not do all that work at once, but rather do chunks of work as I press buttons (e.g. uncollapse, open +/- togglers, etc.)
Joel Bennett wrote: > Ellen H. wrote: > > My tags block is automatically collapsed when I load my page--is that a setting somehwre maybe? > > Wade Ren wrote: > > how is your internet connection? I have over 1000 tags, it takes less than 1-2 seconds > > 1) YOUR OWN tag block always starts collapsed (but other people's don't), but the data is loaded regardless. > > 2) On my home PC, my 1200 tags load in a couple seconds easily ... > > But both of you .... try HIS page. http://www.diigo.com/user/pistos ... even on on my really beefy box at home, with Firefox 3 (beta), that page takes around 6 seconds (I don't know if they've improved this, or if this computer's that much better, or if it's Firefox 3 -- I can retest later if anyone wants to know) -- and I have no weird dragging glitches.
Not to mention the fact that it sometimes persists, leaving a visual artifact even after I submit the bookmark and the diigolet popup closes, and even after I click to hide the bookmarklet bar.
I never use this feature, so it is more than a little annoying for me to deal with. I beg of you, let us turn it off. :(
Did it happen on FF or IE? We will try to reproduce the problem on Opera first to see whether we can solve it.
Thanks.
> Did it happen on FF or IE? We will try to reproduce the problem on Opera first to see whether we can solve it.
Thank you for your attention to the issue, joel. It is appreciated.
I don't use Diigo at all under IE, and in Firefox, I use the extension. So it would only be an issue for me under Opera. I don't suspect you would be able to easily reproduce it, because the particular machine in question has lower hardware specs, and is known to really crawl under even moderate loads.
I hope it's as easy as commenting out a function call or two, and then having an alternate version of the bookmarklet available for use. Hopefully this is not seen as a border case of only a few users that doesn't deserve attention. :(
If the bookmarklet were static code, I'd just change it myself, but my understanding is that it runs remotely and/or updates itself as new versions are published.
> I don't use Diigo at all under IE, and in Firefox, I use the extension. So it would only be an issue for me under Opera. I don't suspect you would be able to easily reproduce it, because the particular machine in question has lower hardware specs, and is known to really crawl under even moderate loads.
=======> Sorry, we can't reproduce it even on a 1.7G CPU PC. Could you change your password to a temp one and give it to joel 【at】 diigo dot com to help us reproduce it? If we still can't reproduce it, we will do a special version for you.
> If the bookmarklet were static code, I'd just change it myself, but my understanding is that it runs remotely and/or updates itself as new versions are published.
=======> It's not static code.
> We reproduced the problem !!. It was caused by several reasons.
> 1) The tagset is big.
> 2) We developed and tested the diigolet on a relatively faster computer, so didn't notice the speed problem
> 3) The most important reason is that One function in a Javascript library we use is slow.
>
> We hand crafted that function and tested it again, it is faster than before. You can try the new version 20070722150447 ( Mouse over to the blank space besides user name in diigolet, you can see the version number). If the version number is not right, please clear the cache and try it again.
>
> Tell us whether this solution solve your problem.
Well, I am happy to report that it seems to be working well. :) Praise be to God! The speed on this slow machine is acceptable, and I don't have that long wait or delay or anything. I can even actually click outside to make the dropdown disappear and not leave an artifact.
Good work, and thank you for your prompt attention and significant effort regarding this issue.
Pistos
http://blog.purepistos.net
Joel Bennett wrote:
> Yeah, I avoid your page too.
>
> Err, I mean ... it's slow for me too. Takes 16s just to download and over 10s on a refresh .... but around 20 seconds to actually finish struggling with the javascript enough to let me scroll with the mousewheel ;-)
>
> You want to see something REALLY annoying? In Firefox, open Pistos' user page, and try to scroll by clicking on the scrollbar gripper and dragging it.
>
> It must be the tags block, however -- because I (only? ha!) have about 1200, and it takes substantially less time to load, and the scrolling is much more responsive. Maybe it would be better to start that block collapsed, and load the data on demand when users click to open it...
>
> Incidentally --- try collapsing the Tags block, and then try again to scroll with the scrollbar -- much better, eh?
> My tags block is automatically collapsed when I load my page--is that a setting somehwre maybe?
Mine starts collapsed too, but I believe it is still vomitting all the HTML data up through the HTTP socket on the initial page hit, and merely keeping it hidden until you uncollapse it.
Pistos Christou wrote:
> Ellen H. wrote:
> > My tags block is automatically collapsed when I load my page--is that a setting somewhere maybe?
>
> Mine starts collapsed too, but I believe it is still vomitting all the HTML data up through the HTTP socket on the initial page hit, and merely keeping it hidden until you uncollapse it.
But note that we have a "recent tags" expanded. The thinking is that most of the time, you will be looking there.
why are all the tags downloaded still? They are needed to auto-complete tags when you filter by tags
> how is your internet connection? I have over 1000 tags, it takes less than 1-2 seconds
According to http://www.speakeasy.net/speedtest/
Download Speed: 5872 kbps (734 KB/sec transfer rate)
I don't think the speed of my net connection is an issue. The bottom line is it is trying to do a lot of work, and I would prefer to be able to have some options to make it not do all that work at once, but rather do chunks of work as I press buttons (e.g. uncollapse, open +/- togglers, etc.)
Joel Bennett wrote:
> Ellen H. wrote:
> > My tags block is automatically collapsed when I load my page--is that a setting somehwre maybe?
>
> Wade Ren wrote:
> > how is your internet connection? I have over 1000 tags, it takes less than 1-2 seconds
>
> 1) YOUR OWN tag block always starts collapsed (but other people's don't), but the data is loaded regardless.
>
> 2) On my home PC, my 1200 tags load in a couple seconds easily ...
>
> But both of you .... try HIS page. http://www.diigo.com/user/pistos ... even on on my really beefy box at home, with Firefox 3 (beta), that page takes around 6 seconds (I don't know if they've improved this, or if this computer's that much better, or if it's Firefox 3 -- I can retest later if anyone wants to know) -- and I have no weird dragging glitches.
Wade Ren wrote:
> wonder if the slowness is browser-dependent. which kind of browsers are you using?
> wonder if the slowness is browser-dependent. which kind of browsers are you using?
As I've said, I tested on both Opera (9.5) and Firefox (2.0).
To Top