I would vote for shared responsibilities The SVN subclipse plug-in is
certainly very sluggish in any situation other that the straight
forward small project, but there is something bizarre with the
PBServer. I am not sure what it is and I don't know how to fix it but
each time I do Shark sample it PBServer.ServerSocketAcceptor comes at
the top. I will do some testing later this week, I have never used
the ServerSocket without timeout and there may be a bug in Apple's
implementation. One minor issue is that the checkbox is only read at
launch time so to do test with and without we need to restart eclipse
each time.
Anyway I agree with you Sebastien the subclipse plug-in it probably
our first line of attack on the sluggishness problem. At least
without the decorator it is usable if slow.
Pierre
On 14-Aug-06, at 9:17 AM, Sébastien Sahuc wrote:
> I confirm that the subclipse plugin is the culprit when importing
> large project. I did send a -QUIT signal to get the thread dump
> where my eclipse was 'refreshing' for too long and every time there
> are many threads deep in the subclipse stack. I would try getting a
> thread dump as well in your case and share with the list your finding.
>
> What I believe is missing from subclipse is a feedback on its
> current progression.
>
> Sebastien
>
> On Aug 13, 2006, at 9:42 PM, Mike Schrag wrote:
>
>> Can you try leaving SVN label decoration off but turn PBServer
>> back on, just to be sure?
>>
>> ms
>>
>> On Aug 13, 2006, at 11:46 PM, Pierre Frisch wrote:
>>
>>> I may be wrong as I have not yet found what is going on exactly
>>> but I did two things I removed the option in PBServer enabled and
>>> I also removed the Team>SVN>Label Decorator>General compute deep
>>> outgoing state for folder and now the contextual menu take a few
>>> seconds (5 top 10) to appear. Before I had the spinning wheel for
>>> ever. As I said I am not sure of anything but I have suspicions.
>>> This only occurs when I import projects from a macro-project. I
>>> don't understand why eclipse would spend 49% of the cpu time in
>>> the socket accept when it is meant to display a contextual menu
>>> and there is not WO application running. When this happens the
>>> machine is pegged to the maximum load, at least my unique G4 chip
>>> is 100% loaded.
>>>
>>> I looked at the code and I agree with you it should not do
>>> anything but it does. I really like to understand what is going
>>> on and without that option the machine is a lot more responsive.
>>>
>>> Thank you
>>>
>>> Pierre
>>>
>>> On 13-Aug-06, at 6:29 PM, Mike Schrag wrote:
>>>
>>>> I think this is a little misleading ... What you're probably
>>>> seeing here is time spent, but not necessarily ACTIVE time
>>>> spent. In particular, this is sitting in a socket accept call,
>>>> which should just be sitting in a select call waiting for
>>>> someone to attach to the socket. So it shouldn't actually be
>>>> DOING anything, rather it's just blocking a socket waiting for
>>>> something to connect to it.
>>>>
>>>> On Aug 13, 2006, at 7:45 PM, Pierre Frisch wrote:
>>>>
>>>>> Hi Mike,
>>>>>
>>>>> I have been investigating why my installation is so
>>>>> unresponsive and I think I have found one of the culprits. When
>>>>> I do right click on some object I get the spinning ball before
>>>>> I get the menu to appear and this can take a long time, I have
>>>>> seen time up to a minute. I have run eclipse with shark and
>>>>> discovered that it spends an inordinate amount of time in
>>>>> PBServer.ServerSocketAcceptor.
>>>>>
>>>>> <Picture 3.png>
>>>>>
>>>>> There may be something wrong there that you want to have a look
>>>>> at.
>>>>>
>>>>> I also have a problem with subclipse that I am investigating so
>>>>> this is not the whole story.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Pierre
>>>>
>>>>
>>>
>>
>
> Sebastien Sahuc
> sebastie..ahuc.net
>
>
> Do you Skype?
>
>
>
This archive was generated by hypermail 2.0.0 : Mon Aug 14 2006 - 13:29:37 EDT