we are working on a project with asp.net core 6 using Visual studio 22 and the build process stuck in
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\Roslyn\csc.exe
the build done successfuly ,but its slow . build time about 1 minute and 30 seconds.
how to reduce build process time?
Any help would be much appreciated.
I am working on Blazor in vs2022 and every change requires recompilation or partial-compilation (hot reload) which was painfully slow.
The following changes I recommend for speeding up build times.
CPU
Get a processor with high turbo clock rate, around 4GHZ-5GHZ.
If you are running a laptop, try get an Intel processor that ends with the H letter. For example, the latest Intel CPUs are 12700H/12900H. These are insanely fast laptop processors which can outperform many desktop CPUs.
Ensure your computer is using the Windows Performance profile or equivalent so that your CPU is not being throttled to save power.
DISK
First prize is a 4th GEN NVME drive paired with a computer that supports GEN4 NVME. Second prize is any NVME drive.
ENCRYPTION
First prize is not to use disk encryption, but if you do need it, opt for hardware encryption as software encryption will consume CPU resources leaving less for compiling. Hardware encryption uses the SSD's own internal encryption (which is always active) to handle the encryption.
My own testing has resulted in +- 40% loss in write performance with software encryption.
RAM
Just make sure you have enough RAM and Windows is not swapping memory to disk in order to compile your project. So most often 16GB RAM is sufficient, but I personally prefer to have 32GB so that more is cached by Windows in memory.
VS2022
Disable visual studio analyzers during build. Some have reported build times increase when this is turned off.
Actually I want to link 64 bit library to my 32 bit application.
I want to use a library which works faster under 64 bits under some circumstances. But i have to link that library to my 32 bit application . Is it possible or not ??
In a word, no. The only way to get compiled 64bit code talking to compiled 32bit code is via some form of IPC (e.g. pipe, named pipe, or network connection). That may well introduce performance bottlenecks of its own, so probably isn't worth the bother.
It is not easy as #robthebloke mentioned. But NVIDIA RTX Remix Runtime does it somehow, making older 32bit games running on 64-bit vulkan driver (bypassing 2-4GB virtual memory limit).
I am creating a quite simple application which reads and display text files and search through them.
I am asking myself if there is any interest for me to propose 32 and 64 bits version to the user.
Is the difference only in having access to more memory heap size with the 64 bit version or is there any other interest ?
Will a 32 bit compiled program work on a 64 bits JVM (I assume yes)
The only differences between 32-bit and 64-bit builds of any program are the sizes of machine words, the amount of addressable memory, and the Operating System ABI in use. With Java, the language specification means that the differences in machine word size and OS ABI should not matter at all unless you're using native code as well. (Native code must be built to be the same as the word-size of the JVM that will load it; you can't mix 32-bit and 64-bit builds in the same process without very exotic coding indeed, and you shouldn't be doing that with Java about.)
The only times that have swung it for me is when there have been native libraries involved that have pushed it one way or the other. If you're just in Java land then realistically, unless you need >4GB of heap size, there's very little difference.
EDIT: The differences include things like it uses slightly more memory than 32 bit, significantly more if you're using a version before 6u23 and aren't using -XX:+UseCompressedOops. There may also be a slight performance difference between the two, but again nothing huge.
SandCastle is unable to process our class library because it crashes with an OutOfMemoryException exception during XSL transformation.
What can we do about that, except for the obvious, buy more memory? The problem is that this is our developer machines with 3.3GB memory on a 32-bit OS so basically we either have to upgrade to 64-bit and more memory (which won't happen for a while) or set up a virtual server to do this with lots of memory (which will impact production servers).
I seriously doubt we have the biggest class library in the world that requires help files, so what options do we have? Is there a magic "Do not crash with out of memory errors" setting that we forgot to turn off?
If you're on 32 bit Windows, your user process will only be able to address 2 GB memory per default (3 GB is run as large address aware). The 2 GB are used for everything in the process, so the .NET runtime, standard libraries, booking and so forth all take their chuck. In my experience that leaves about 1.5 GB for .NET applications on 32 bit.
You can get access to more memory by using the large address aware switch, but it doesn't come for free if you're on 32 bit Windows. Moving to 64 bit Windows will let your 32 bit application access the entire 32 bit address space and thus give you 4 GB addressable space.
I've recently written a blog entry with details about memory usage for .NET applications, but since I blog in Danish, you may not be able to read it. However, if you want to have a look, the link is: http://kodehoved.dk/?p=156
You may also find this MSDN blog post relevant: http://blogs.msdn.com/maoni/archive/2007/05/15/64-bit-vs-32-bit.aspx
Possibly better suited for "Rack Overflow", but from a developer's point of view, what are the advantages and disadvantages of running IIS (serving both legacy classic ASP and .NET) as a 32bit process instead of a 64bit process on a 64bit windows host?
The main advantage of 32/64 (iis/server) over 32/32 seems to be the ability to go up to 4gb in memory per IIS process.
The advantages I expect of 32/64 over 64/64 appear to be that it's easier to access legacy 32-bit in-process DLLs (of which we still have one from a partner vendor we can't move away from immediately) and perhaps a smaller memory footprint for the same code given smaller memory pointers.
Are there any performance benefits of 64/64 over 32/64 or anything else that would warrant a full switch now? Have I made any false assumptions here?
The only perf advantage to running IIS on 64bit vevrsus 32-bit is to allow access to a much larger memory address space.
If you are doing normal ASPX page processing, then it's likely you don't need to address more than 4gb from any single process. Suppose you run in 32-bit mode with a web-garden with multiple worker processes on the same machine. In that case each process can address up to 4gb.
The big advantage can come when you perform caching. A 64-bit process can maintain a huge in-memory cache (assuming you have the 32GB or more of RAM to support it) to allow you to cache complex page content or data, on the web server. This allows perf gains when the data is more expensive to generate than it is to retrieve - for example if the data is an elaborated form (let's say the result of a monte carlo simulation), or if the data resides off-box and the network IO time is much more expensive than cache-retrieval time.
If you do not use caching, then 64-bit IIS is not going to help you. It will require 64-bit pointers for every lookup, which will make everything a little slower.
64-bit servers are much more effective when used for databases like SQL Server, or other data management servers (let's say, an enterprise email server like Exchange), than for processing servers, such as IIS or the worker processes it manages. With a 64-bit address space, servers that need to manage data can keep much more of that data in memory, along with indexes and other caches. This saves disk IO time and elaboration time when a query comes in. Most Web apps don't need to address more than 4gb from a single process.
Maybe a useful analogy: In transport, an large SUV is like a 64-bit machine, while a regular, compact passenger car is like a 32-bit server. You can carry much more stuff in a large SUV, and it has a larger towing capacity, seating for 8 people, and a GVWR of 8600 lbs. But with all that, you pay. The truck is heavier. It uses more fuel. If you are only carting around 2 people and one duffel bag, you don't need an SUV. You'll be better off with the smaller vehicle. It can be speedier and more efficient.
I don't think you've made any false assumptions. But I'd say, no, there's likely to be no performance difference between any of the scenarios you outlined. 32 on 64 on Windows does not operate at a penalty. 64 on 64 may give some slight performance boost, but that's dubious. There may be some memory savings with a 32-bit process, but this is likely negated by the thunking required to run the process in the first place.
The only benefit is the DLL issue you mentioned. That could be a reason for upgrading as well (if you have something specifically 64-bit that you need to use).
I've had an experience where moving from a 32bit Windows 2003 Server to a 64bit Windows 2003 Server both running IIS 6 and the performance of the ASP.NET 3.5 website was unacceptable.
The 64bit server would run a clear 2 seconds behind the 32bit one consistently.
After switching IIS 6 to run as a 32bit worker process, the performance was equal and comparable once again.
I haven't verified it, but I think it might only apply to IIS6 win2k3, as testing I've done with IIS7 x64 (Vista) and a 64bit IIS worker process seems to perform just fine.
The process to swap to the 32bit process was quite simple. Here is the KB article with the supporting details:
http://support.microsoft.com/kb/894435/en-us
ASP.NET 2.0, 32-bit version
To run the 32-bit version of ASP.NET 2.0, follow these steps:
Click Start, click Run, type cmd, and then click OK.
Type the following command to enable the 32-bit mode:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
Type the following command to install the version of ASP.NET 2.0 (32-bit) and to install the script maps at the IIS root and under:
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
Make sure that the status of ASP.NET version 2.0.50727 (32-bit) is set to Allowed in the Web service extension list in Internet Information Services Manager.
See the KB article for setting back to 64-bit.
For memory availability, refer to this msdn blog.
Memory availability. For my application, we got what we needed switching from 32 bit process on 32 bit OS to 32 bit process on 64 bit OS, without the trouble of replacing 3rd party libraries. So, we stopped there. Benefits are: 1) 2-3x effective memory available to each IIS worker process and 2) In a 32 bit OS where the web site uses a lot of memory, other system processes and web sites compete for limited total memory. For your application, look at how much memory do your worker processes use. If each WP isn't using a lot of memory (well over 1GB), 64 bit worker processes won't help much.
For performance, I think you have to test your own applications in both configurations. Dave's post above indicates that you might have performance degradation with 64 bit. As cheeso notes, some applications may see benefits from caching (2GB + of cache is a lot, though). Except for limited and simple applications, I don't think we are going to be able to make performance generalizations. We might be able to point to specific technologies that perform better or worse.
Besides the obvious memory differences, 32 bit processes on a 64 bit OS have to run in something called "Windows on Windows" or WOW mode. It's basically a thunking/emulation layer. There is a performance penalty if you pay close enough attention.
This is actual advice from Microsoft: "We recommend that you configure IIS to use a 32-bit worker processes on 64-bit Windows. Not only its compatibility better than the native 64-bit, performance and memory consumption are also better."
Please refer to this link posted in one of the comments above and published 05/14/2020:
https://learn.microsoft.com/en-us/iis/web-hosting/web-server-for-shared-hosting/32-bit-mode-worker-processes
I cannot claim to understand exactly why, but this advice is very clear, with 64bit workers virtual address space is bigger so a 32bit worker is generally more efficient