My entire tool set and work environment is inside WSL.

I've determined that the issue for me is the performance of the file
system.  I had to remove the (bundled) antivirus software to get even where
I am now.  But I have no evidence that even doing windows-native operations
with this disk are fast.  I suspect that even though this is an SSD it's
not a very fast one.  It did get twice as fast when I turned off the new
Windows 11 "climate change" feature, which apparently conserves energy by
throttling the hell out of everything, including disk access.  So maybe
this is still being throttled to some degree and I have to figure out where.

Karl


On Thu, Nov 24, 2022 at 3:23 AM Jan Høydahl <jan....@cominvent.com> wrote:

> I’m not on Windows myself, but I think the trick is doing the git clone to
> the WSL file system. So you may have one checkout for use with windows and
> another for use within wsl.
>
> And if you’re a CLI person, there’s a GitHub cli tool ‘hub’ that is handy:
> https://hub.github.com/
>
> Jan Høydahl
>
> 17. nov. 2022 kl. 16:49 skrev Dawid Weiss <dawid.we...@gmail.com>:
>
> I never used WSL but it does seem like the problem there:
>
> "As you can tell from the comparison table above, the WSL 2
> architecture outperforms WSL 1 in several ways, with the exception of
> performance across OS file systems, which can be addressed by storing
> your project files on the same operating system as the tools you are
> running to work on the project."
>
> https://learn.microsoft.com/en-us/windows/wsl/compare-versions
>
> Dawid
>
>
> On Thu, Nov 17, 2022 at 1:11 PM Robert Muir <rcm...@gmail.com> wrote:
>
>
> if your machine is really 12 cores and 64GB ram but is that slow, then
>
> uninstall that windows shit immediately, that's horrible.
>
>
> On Thu, Nov 17, 2022 at 5:46 AM Karl Wright <daddy...@gmail.com> wrote:
>
>
> Thanks - the target I was using was the complete "build" target on the
> whole project.  This will be a valuable improvement. ;-)
>
>
> I have slow network here so it is possible that the entire build was slow
> for that reason.  The machine is a new Dell laptop, 12 cores, 64GB memory,
> but I am running under Windows Subsystem for Linux which is a bit slower
> than native Ubuntu.  Still, the gradlew command you gave takes many minutes
> (of which a sizable amount is spent in :gitStatus - more than 5 minutes
> there alone).  Anything less than 10 minutes I deem acceptable, which this
> doesn't quite manage, but I'll live.
>
>
> Karl
>
>
>
> On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss <dawid.we...@gmail.com> wrote:
>
>
>
> Thank you for the comment.
>
>
>
> Sorry if it came out the wrong way - I certainly didn't mean it to be
> unkind.
>
>
>
> It took me several days just to get things set up so I was able to commit
> again, and I did this through command-line not github.
>
>
>
> These things are not mutually exclusive - I work with command line as
> well. You just push to your own repository (or a branch, if you don't care
> to have your own fork on github) and then file a PR from there. If you're
> on a slower machine - this is even better since precommit checks run for
> you there.
>
>
>
> The full gradlew script takes over 2 hours to run now so if there's a
> faster target I can use to determine these things in advance I'd love to
> know what it is.
>
>
>
> Well, this is crazy long so I wonder what's happening. I'd love to help
> but it'd be good to know what machine this is (disk, cpu, memory?) and what
> the build command was. Without knowing these, I'd say - run the tests and
> checks for the module you've changed only, not for everything. How long
> does this take?
>
>
> ./gradlew check -p lucene/spatial3d
>
>
> It takes roughly 1 minute for me, including startup (after the daemon is
> running in the background, it's much faster).
>
>
> There are some workflow examples/ hints I left here:
>
> https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22
>
>
> Hope it helps,
>
> Dawid
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Reply via email to