Re: [platform-dev] Impact of Windows Defender and Eclipse startup

[Rolf Theunissen]

Note that the particular issue mentioned happend on a computer with a 
McAfee virus scanner. I think that in this case p2 may not assume that a 
file is available directly after unpacking, or something like that. Only 
after it is really there, i.e. unlocked, it should be moved. And indeed, 
this thread made me point to the virus scanner when I saw this error in 
the event log.


Op 6/15/2019 om 4:58 PM schreef Ed Merks:
I believe this problem also affects p2, sometimes with very bad 
consequences beyond just being slow.  E.g., p2 often downloads things 
to a temporary location then p2 immediately moves the file when the 
download is complete.  When a virus scanner is busy scanning the file 
such that it's temporarily locked, the move will fail.  This causes 
the installer to fail and causes updates to fail.  The following 
appears to be an example of that:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=548299#c3


On 15.06.2019 09:33, Christian Pontesegger wrote:

TL;DR - Windows Defender adds 1.5 minutes or more to Eclipse launch

Same situationin our company. Windows defender blocks not only Eclipse
startup,but also kicks in when we start a new RCP session from our
development IDE. Then I guess it is scanning the jars of the target
platform.

Interesting thing is that this does not happen all the time. Sometimes
it happens on the first Eclipse startup after a reboot, sometimes after
  hours of working. I work with multiple IDE instances at the same time,
frequently starting RCP debug sessions. From a gut feeling I would say
that scanning happens 1 out of 10 times.

And when it happens it is really annoying. Eclipse for Platform
developers takes 5 minutes to start on a modern laptop with SSD.

As our users also complain a lot about the slowliness of Eclipse I
would love if there were a way to teach windows defender that these
jars can be trusted somehow.

Christian
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Startup times of bundles in Build id: I20190612-0115

[Lars Vogel]

Hi Thomas,

thanks that looks very useful.

Btw. you had a small but important typo, I think, I think it should be
set to true instead of false.

Correct value:

org.eclipse.osgi/debug/bundleStartTime=true

Best regards, Lars

On Fri, Jun 14, 2019 at 2:49 PM Thomas Watson  wrote:
>
> I think we should start using the following trace option to report the true 
> startup times of bundles:
>
> org.eclipse.osgi/debug/bundleStartTime=false
>
> I added this option in https://bugs.eclipse.org/bugs/show_bug.cgi?id=546380 
> because the old trace option only recorded the time of the BundleActivator.  
> But as you move to reducing or removing the BundleActivators from bundles 
> this trace time becomes less useful.
>
>
> Tom
>
>
> - Original message -
> From: Lars Vogel 
> Sent by: platform-dev-boun...@eclipse.org
> To: "Eclipse platform general developers list." 
> Cc:
> Subject: [EXTERNAL] [platform-dev] Startup times of bundles in Build id: 
> I20190612-0115
> Date: Thu, Jun 13, 2019 5:32 PM
>
> Friends of Eclipse,
>
> as it is now a good old tradition that I send around the startup time
> of our bundes, before is a list of our current startup times as
> reported by Equinox logging. I use the Eclipse SDK + Egit for the
> measurement.
>
> See 
> https://www.vogella.com/tutorials/EclipsePerformance/article.html#example-tracing-the-startup-time-of-plug-ins
> how to generate this data yourself.
>
> If you have ideas how to fix the slow starting bundles, please create
> bugs and attach Gerrits to them.
>
> Best regards, Lars
>
> 449ms org.eclipse.jdt.ui_3.18.100.v20190611-1746
> 394ms org.eclipse.egit.ui_5.4.0.201905221418-m3
> 265ms org.eclipse.egit.core_5.4.0.201905221418-m3
> 255ms org.eclipse.jdt.core_3.18.0.v20190522-0428
> 190ms org.eclipse.ui.trace_1.1.500.v20190513-1223
> 185ms org.eclipse.core.runtime_3.15.300.v20190508-0543
> 164ms org.eclipse.core.resources_3.13.500.v20190611-2119
> 141ms org.eclipse.update.configurator_3.4.300.v20190518-1030
> 141ms org.eclipse.ui.workbench_3.115.100.v20190612-0253
> 141ms org.eclipse.equinox.simpleconfigurator_1.3.300.v20190611-1008
> 132ms org.eclipse.emf.common_2.16.0.v20190528-0845
> 129ms org.eclipse.pde.ui_3.11.0.v20190520-2013
> 129ms org.eclipse.osgi_3.15.0.v20190611-1353
> 121ms org.eclipse.equinox.console_1.3.300.v20190516-1504
> 114ms org.eclipse.equinox.p2.ui.sdk.scheduler_1.4.300.v20190611-1008
> 93ms org.eclipse.pde.core_3.13.100.v20190611-0906
> 76ms org.eclipse.jsch.core_1.3.500.v20190413-1338
> 72ms org.eclipse.core.jobs_3.10.500.v20190611-2049
> 61ms org.eclipse.core.net_1.3.600.v20190612-0326
> 61ms org.apache.felix.gogo.runtime_1.1.0.v20180713-1646
> 60ms org.apache.felix.scr_2.1.14.v20190123-1619
> 46ms org.eclipse.jdt.launching_3.14.0.v20190508-0531
> 38ms org.eclipse.emf.ecore_2.18.0.v20190528-0845
> 37ms org.eclipse.core.contenttype_3.7.400.v20190612-0059
> 35ms org.eclipse.equinox.common_3.10.400.v20190516-1504
> 34ms org.eclipse.equinox.app_1.4.300.v20190611-1153
> 32ms org.eclipse.equinox.registry_3.8.400.v20190516-1504
> 32ms org.eclipse.debug.core_3.13.400.v20190612-0015
> 24ms org.eclipse.equinox.event_1.5.100.v20190528-1257
> 21ms org.eclipse.equinox.preferences_3.7.400.v20190516-1504
> 21ms org.apache.felix.gogo.shell_1.1.0.v20180713-1646
> 16ms org.eclipse.team.core_3.8.700.v20190611-1101
> 16ms org.eclipse.equinox.p2.reconciler.dropins_1.3.100.v20190611-1008
> 13ms org.eclipse.pde.launching_3.7.600.v20190513-1223
> 10ms org.eclipse.e4.ui.workbench_1.10.0.v20190529-1505
> 7ms org.eclipse.ui.navigator_3.8.100.v20190612-0151
> 7ms org.eclipse.equinox.p2.repository_2.4.500.v20190611-1040
> 6ms org.eclipse.e4.ui.workbench.swt_0.14.700.v20190611-2058
> 6ms org.apache.felix.gogo.command_1.0.2.v20170914-1324
> 5ms org.eclipse.ui.editors_3.11.600.v20190611-2019
> 5ms org.eclipse.equinox.p2.core_2.6.100.v20190611-1008
> 4ms org.eclipse.core.filebuffers_3.6.600.v20190519-2344
> 3ms org.eclipse.ui.workbench.texteditor_3.12.100.v20190611-1038
> 3ms org.eclipse.ui.ide_3.15.300.v20190612-0253
> 3ms org.eclipse.ui_3.113.0.v20190513-2118
> 3ms org.eclipse.e4.tools.services_4.8.200.v20181022-1512
> 2ms org.eclipse.help_3.8.400.v20190423-0921
> 2ms org.eclipse.equinox.security_1.3.200.v20190516-1504
> 2ms org.eclipse.equinox.p2.ui_2.5.600.v20190611-1008
> 2ms org.eclipse.equinox.p2.garbagecollector_1.1.200.v20190611-1008
> 1ms org.eclipse.ui.views.log_1.2.600.v20190519-1034
> 1ms org.eclipse.ui.net_1.3.400.v20190519-2354
> 1ms org.eclipse.ui.monitoring_1.1.400.v20190517-1612
> 1ms org.eclipse.jdt.core.manipulation_1.11.200.v20190520-0718
> 1ms org.eclipse.equinox.p2.engine_2.6.400.v20190611-1008
> 1ms org.eclipse.emf.ecore.xmi_2.16.0.v20190528-0725
> 1ms org.eclipse.e4.ui.css.swt_0.13.500.v20190513-2118
> 1ms org.eclipse.core.filesystem_1.7.400.v20190518-1151
> 1ms org.eclipse.core.expressions_3.6.500.v20190612-0059
> 0ms org.eclipse.tips.ide_0.1.500.v20190402-1511
> 0ms org.eclipse.equinox.p2.metadata.repository_1.3.200.v20190611-1040
>
>
> --
> 

Re: [platform-dev] Impact of Windows Defender and Eclipse startup

[Rolf Theunissen]

I do agree that this is a Eclipse IDE (or even Eclipse Foundation) 
issue. Windows Defender should be told or trained to treat the Eclipse 
(signed) executables, ddls and jars as trusted. I think the following 
blog post is a good starting point to improve upon the current situation.


https://www.microsoft.com/security/blog/2018/08/16/partnering-with-the-industry-to-minimize-false-positives/

Rolf

Op 6/14/2019 om 7:24 PM schreef Tim Webb:

Mike,

Absolutely. My concern is a bit more general -- locally I can simply 
setup exclude rules in Windows defender to not protect "eclipse.exe"  
The problem I see is how this impacts the massive user base of Eclipse 
users.  If your first experience with Eclipse involves a few minute 
coffee break after downloading it, I'm afraid it predisposes people to 
think it is slow.  The impact seen for larger IDEs is even more 
significant.


I'll have a blog published shortly that provides the workaround for 
users but I'm wondering about other creative ways we could help users 
know about this. AKA if the Eclipse executable itself detected Windows 
Defender scanning and let the user know about the workaround, then at 
least they'd know that Defender is slowing things down, not Eclipse 
itself.  Or if we were able to somehow have Microsoft "trust" the Jar 
signing certificate from Eclipse.org and avoid doing so extensive 
validation of plugins originating there.


Ultimately this is more of a project/product level concern as I see it 
for the Eclipse IDE than just a one-developer workaround issue.  I may 
be wrong though. ¯\_(ツ)_/¯


Tim

On Fri, Jun 14, 2019 at 11:56 AM Mike Wilson > wrote:


Yikes! Is it possible to keep the extracted zip around, in a way
that Defender wouldn't have to rescan it?
McQ.

- Original message -
From: Tim Webb mailto:t...@genuitec.com>>
Sent by: platform-dev-boun...@eclipse.org

To: platform-dev@eclipse.org 
Cc:
Subject: [EXTERNAL] [platform-dev] Impact of Windows Defender
and Eclipse startup
Date: Fri, Jun 14, 2019 8:41 AM
TL;DR - Windows Defender adds 1.5 minutes or more to Eclipse
launch
Lately, I've heard some colleagues grumbling about how Eclipse
startup seems slower. I'll admit that I'm recently back on
Windows after years on Mac and was surprised. Some quick metrics:
0:05 - time to extract 354mb JEE 2019-06 RC1 zip
1:28 - time spent by Windows Defender before Eclipse workspace
prompt
A similar slowdown is observed after Eclipse updates, either
itself or when adding plugins.
I'm running on a fast laptop (latest Intel i7, 32gb ram,
etc.).  A colleague had a large Eclipse setup blocked for 11
minutes before he got the workspace prompt, though likely had
some other load on the box at the time.
I've been googling around trying to find ways to
submit/pre-approve plugins, etc. but so far Windows Defender
doesn't seem to have ways that other virus software does. My
assumption is it is scanning all jar files as "potential
malicious executables."
Is this something others have observed/already pursued
solutions for? Yes, there is a workaround of just turning
off/excluding folders from Windows Defender, but as plugin
makers, we're concerned about the perceived impact of "Eclipse
is slow" that this gives.
Tim
___
platform-dev mailing list
platform-dev@eclipse.org 
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org 
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



--

Cheers,
Tim
__

*Timothy R. Webb*
Vice President, Operations
Genuitec, LLC , follow @timrwebb 


or connect at linkedin.com/in/trwebb 


___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev