Dealing with an issue where loading a large file into memory in a Silverlight 4 app leads to a an out of memory exception, and a crash. The file is ~100MB. I am trying to determine if Silverlight has some sort of default limit on RAM.
I can tell you only about Silverlight 5, as I'm having issue with it now.
As some author has written here, on any machine (x86, or x64) for 32-bit process the memory limit by default is 2 GB. If special flag in .exe header is set (called IMAGE_FILE_LARGE_ADDRESS_AWARE), then the limit is increased to 4 GB. However, in OOB mode Silverlight app is lauched by C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe, which is 32-bit process that doesn't have appropriate flag set, so it has 2GB memory limit MINUS ~800 MB for .NET CLR usage.
In short terms: RAM limit (at least in my case, OOB mode) is 1.3 GB.
(sorry I'm answering 1.5-years-old question, but people may want to know...)
Related
On a windows server 2019, I have many directories under a main images directory, each with about 100 images.
A 32-bit executable currently relies on disk-caching for serving the images. The current load on the exe is about 100 images per second. It's coming to the point where It seems disk-caching only slows the threads - each calling for a different image.
My initial thought is to have a 64-bit exe load everything in-mem (about 200GB RAM). The RAM on the server is sufficient. Once loaded in the 64-bit exe - either find a way to share the memory between the 32-bit and the 64 bit exe's, or use TIdTCPServer on the 63 bit and TIdTCPClient on the 32-bit, calling each time for the image.
Also, my initial thought of the shared-mem is the limit of the 32-bit EXE (unless there is a way) to access the shared-mem from the 64 bit.
Only other way I see possible is preloading MSSQL-server 2019 with the images in a memory-table - which would guarantee performance, reliability and lower the development/testing time on the TidTCP svr/cli.
The main idea is is to have a good reliable solution with the lowest headache for dev/test/lifecycle support.
Any thoughts with applicable code are welcomed
TIA
I am trying to render a video project that I created with kdenlive. It is about 50 minutes long and contains a dozen short 1080p video clips and several hundred still images (mostly 18MP). melt runs and proceeds to consume all 4GB of my RAM, at which point it is killed by the kernel.
I have tried both mlt 0.9.0 that came with Ubuntu 14.04, and I have tried the latest version, 0.9.8, that I compiled myself. No difference.
Is this indicative of a problem with melt, or is it just not realistic to render this kind of project with only 4GB of RAM?
Do you have 4 GB free RAM before launching melt? I do expect a project of that complexity and resolution to consume near 4 GB. You can readily remove half the project contents and make a test to see how it compares. There is a workaround that requires editing the project XML to set autoclose=1 on the playlists, but that is not set by default since it only works with sequential processing and will break handling in a tool that seeks such as Kdenlive.
.Net winform application.
I used several memory profiler, including CLR profiler, DotTrace memory, Net memory profiler.
The tools gave the result that the allocated memory was 38-40M. But I found that working set was 300-400M in task manager(almost the same size as Peak working set or memory or commit size.
So what's the difference between the two results? What do the results mean?
those tools may show you private bytes or managed heap size, this does not include, e.g. memory mapped file, either page file backed or disk file backed, your app may be r/w ing
big mapped file, so working set looks big, or your app just load too many dll/assemblies.
VMMAP (from sysinternals) can give a clear overview of memory type/size in your app.
I'm currently trying to determine the available disk space from my Silverlight application.
My app can download a lot of data (video files) and obviously, this can fail if the disk space isn't there.
I know I can catch exceptions on writes, but that will not lead to a very user-friendly experience, because the information will come too late and cause useless waits.
In regular .NET, I would be using DriveInfo (see How do I retrieve disk information in C#? for an example), but that class isn't present as of Silverlight 5, even in elevated trust mode.
So, is there a way to determine the available space on a drive in Silverlight?
Update:
I'm fine with requiring Elevated Priviledges for my application.
I'm also fine with Silverlight 5 only solutions.
I need something that works on both Windows and Mac OS, so PInvoke/COM interop is not an option.
There has been filebrowser demos out there written in Silverlight but they would run with elevated trust.
That means that you would have to make the user immediately suspicious of your application when they first run it.
It's probably a better user experience to just have a well worded error message for when the user runs out of space.
Another option would be to try an increase the isolated storage quota by the size of the biggest video available.
http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstoragefile.increasequotato(v=vs.95).aspx
Then when that fails just let the user know that no more space can be allocated for the app had that he may need to delete older videos.
I'm adding my answer here to sum up my discoveries:
TL/DR: there is no easy way to get available disk space in Silverlight 5 that is cross-platform (Windows/Mac OS).
You can't get available disk space with standard Silverlight calls. DriveInfo is missing from Silverlight 5, elevated privileges don't come into account here.
Quota is useless for that kind of issue, it doesn't take into account available disk space.
There are workarounds for Windows only, requiring elevated trust, using P/Invoke into Win32.
For a detailed support of filesystem, see this article: http://www.codeproject.com/KB/silverlight/FileExplorerInSilverlight.aspx
Fall-back is to check for exceptions when writing files and present the user with a message at the time of writing. People have also suggested pre-writing the file when the download start to ensure sufficient disk space.
I am writing code using VS.Net 10 and SlimDX to render 3D content on a D3DImage. It works perfectly under 32 Bit Windows XP. However, after migrating to 64 bit Windows 7 (quad core and 4 GB Ram), the same code does not work any more. The symptom is that after rendering about 10 or 20 times, the D3DImage's IsFrontBufferAvailableChanged event is raised and the property of IsFrontBufferAvailable has a value of false.
I have checked everything I can think of, e.g. RenderCapability.Tier, calling SetBackBuffer, checking the device (in fact it is DeviceEx type) after the front buffer is lost, updating video card driver (nvidia 9500 GT 1G RAM), etc. None of them worked.
One thing that may contribute to the problem is that the image control which uses D3DImage as the source is not created on the GUI thread. I am doing to reduce the work load of the GUI thread to make the application more responsive. Of course, I have been using Dispatcher.Invoke to avoid threading problems. Again, it works perfectly in XP.
Any help is much appreciated. Thank you in advance.
I think there is a x64 version of the slimdx.dll.. if you are using the x32 version, that could be the problem.