In this picture, the virtual address space is larger than the physical address space. Is it possible for it to be the other way around? How would that work because how would the virtual address space have enough room to reference everything in the physical address space if it's smaller?
How would that work because how would the virtual address space have enough room to reference everything in the physical address space if it's smaller?
It wouldn't have enough space, which wouldn't be a problem at all. Why would each virtual address space need to cover all physical memory? And in fact, that practically never happens on most computers. Part of the motivation of virtual memory is to segregate each process's memory so they won't step on each other's toes.
Even in your picture, the virtual address space does not reference everything in the physical address space. The red pages don't belong to the process, meaning they don't occur in the virtual address space.
32 bit computers using PAE to use more than 4 GiB physical memory are an example. Each virtual address space is at most 4 GiB, even though there can be 8 GiB or more of physical RAM in use.
Related
I'm testing on an iPhone 4 running iOS 7.1 attached to Xcode 5.1.1. I don't understand why I am getting memory warnings and even crashes when instruments shows my app is only using a few megabytes and there is plenty of memory free (see attached). Any ideas?
Update:
In instruments, as I suspected, I found no leaks, but the "Anonymous VM" size seems unduly large and filled with image data. Each table cell in my app displays a JPEG. Perhaps I should be pre-scaling these images and that is the cause of the large Anonymous VM size... More investigation to be done.
It turned out images displayed in UIImageViews in each and every table cell were being stored in memory at their full size, not the scaled size (size of the UIImageView). This only showed up in the "Anonymous VM" in Instruments (since iOS only stores references to your images in your application heap and the actual image caches are in system memory it seems), not in the basic memory usage displayed in Xcode. I resolved the issue by pre-scaling my images before putting them into the UIImageViews of the table view cells. There were no leaks.
Instrument is sometimes imprecise about the real memory used. The best way to measure is to print the memory usage on the console.
I found the code on this thread: Programmatically retrieve memory usage on iPhone
I have a number of calls to [UIImage imageNamed:] and I know the caching keeps the bitmaps allocated in virtual memory.
However I have a number of small images such as buttons and icons and the total data size is not anywhere near the virtual memory allocations in the ImageIO region.
How large do images become once fully mapped in virtual memory?
How are images placed in Interface builder referenced? Via file URL or cached in VM?
If the image is mapped as a bitmap. then its size will be width * height * size per pixel. So if you have a 10 * 10 image that is 24 bytes per pixel. then it'll be 240 bytes in memory.
I'm using twaindotnet to scan an image with 2400 DPI. Whenever I scan a full page in color I get a message that there is not enough memory to perform this action. I tried it on a different computer with around 4 GB of ram and got the same error message.
If I scan the image as black and white or gray-scale I don't get any error and everything is working fine.
Is that a problem that is related to the scanner driver (Canon 9000F) or is this a general TWAIN problem?
gray-scale images have a bit depth varying from 2 to 8. for an image of legal size and of 2400 dpi, the size can be 163 MB ~ 654 MB.
color images have higher bit depth. take 32 for example, the image of the same size and dpi can be around 2.62 GB. plus the memory occupied by other applications, 4 GB memory likely runs out.
File Size = (height x width x bit depth x dpi2) / 8
dpi2 means dpi square
Looks like that Twain library is scanning to memory, the Twain specification also has a file transfer mode which is generally used for very large images (ICAP_XFERMECH). Twaindotnet may allow you to choose the file transfer mode when scanning.
I'm developing a reader application for Bada and have a silly question.
Does a smooth way to convert pt size to pixel size exist?
I found something like this, but I'm still hoping you could apply some formula and be happy with it.
Points are a "real-world" length unit (they are generally defined as 1/72 in), but pixels do not have a definite real world size, since this depends on the resolution of the device.
For example, the pixels on my screen are about 0.3 mm wide, while the ones of my phone are about 0.15 mm, and the "pixels" of my laser printer are 0.02 mm wide. Thus, to go from pixels to real world units, you need the resolution of the specific device, i.e. the pixels/real world unit ratio, which, most often, is expressed in DPI (dots per inch, where "dot" is intended as "pixel" for devices that work with pixels).
When dealing with printing/scanning devices the "real world size" is important, so it's almost always provided by the OS in some way and is correct; on the other hand, with screens the situation is quite different.
In most situations you don't really care about the "real world size" of stuff displayed on screens, since no one is ever really measuring anything on the screen. Also, onscreen layouts are often partly done in pixels for a variety of reasons (simplicity being the first).
On the other way, text and other elements' sizes are often specified in points, twips and other "real world units", and in general good window layouts should be done in "real world units" to be easily adapted to screens with high pixel densities, where pixel-based layouts would be unreadable.
For this reason, the OS usually provides a DPI value for the screen, but in general it's left to the same default value (usually 72 DPI) regardless of the real attached screen (also to avoid breaking badly designed interfaces), but leaving it configurable to the user, to let him adjust it to a comfortable value.
As for Bada, I read here that the OS does not provide neither a real neither a "fake" DPI value, so there's no real way to convert from points to pixels. On the other hand, you could simply use the usual "default" 72 DPI value for your conversions. Notice that 72 DPI wasn't chosen by chance: since there are 72 pixels per inch, and 72 points per inch, you simply assume that a point is equal to a pixel. Not correct, but in your case "good enough".
Assuming 72 DPI for bada is not a good choice since modern mobile devices have DPIs around 200-300.
Unfortunately, Bada wanted to go iPhone way, and have a few devices and you would release your application on each device, which has fixed features. This way, you can visit samsung web, read real size of their screen. Then compute real DPI yourself for each device and store it to table. Runtime, you can get device name and try to search your table.
AFAIK you have to upload your application to bada shop for each device separately. And they assume from Bada SDK that you will compile for each target different application. Target is specified by screen resolution, and I guess you can expect real screen to be this size.
Well, i think think this design is stupid, but might be really the way how they expect you to develop for their platform.
Currently I am writing an iPad app. I am using a lot of images in this app around 40 MB of images!
This app works fine in simulator but crashing on device. I think the problem is with memory.
I wanted to know how much memory I can use on iPad?
Thanks
Saurabh
Remember that 40MB of image files on disk is far more when put in memory. On disk they are compressed but once you load it into memory you use just as much memory as a uncompressed image. If I remember right its (width x height x (bits per pixel/8)) = mem usage so for a full screen image (1024x768x(16/8)) = 1,572,864 so around 1.5 MB of RAM while on disk it may only be a couple hundred KB.
The iPad has 256 MB of memory, and of which, only around 100 to 120 are usable in an application. Note that this number is variable as the VM releases memory from previous applications, and could be less if you're using apps like iPod in the background.
My suggestion, look at what you can do to reduce the size of your images, through different resolutions, lower quality images, or such.