Which version of Windows is better for SNAP? In my laptop, it works very very slowly in all operations, and finally, it crashes.
SNAP 7.0
Sentinel 2 products
Windows 10
Core i5
1 GB VRAM
4 GB DDR3 Memory
500 GB HDD
Problem with my laptop or SNAP?
I have no problems with other similar software like ENVI, ERDAS, ArcMap.
4GB RAM is under the recommended minimum of 8GB. If possible add more RAM. You can try optimising the Java VM settings under Options/Performance and see if it helps, but at 4GB there’s little room for improvements.
This amount of RAM is not enough to support some operations.
HHD makes writing/reading operations slow. SSD makes the utilization of SNAP more smooth and enjoyable
In SNAP 6 I didn’t face up similar problem,
But, Why? , and How could repair this problem?
Working in SSD in Drive C: my case , could solve the issue! (Doesn’t solve the slow of reading)
I’m not sure of what you mean.
Are you saying that HDD were fine in SNAP 6 but became slow in SNAP 7 ?
So is it solved or not ?
What I was trying to say is that using HDD, you can expect ~50Mo/sec of writing operation while nvme SSD can go up to 3Go/sec. For mutli-Go input images, it completely changed how SNAP was performing
Falah, there is a bug in SNAP7 that slows opening of images in the GUI that has already been fixed in the development branch. A module update is planned for next week.
https://senbox.atlassian.net/browse/SITBX-651
https://senbox.atlassian.net/browse/SNAP-1159
I hope this will solve your particular issue.
Yes, exactly this what I meant,
Unfortunately not,
@falahfakhri Ok. I guess the reply of @mengdahl answered your questions 
Waiting the update, thanks a lot Marcus,
From where?
You can find the performance settings in the menu. Under Tools / Options and then select the Performance tab.
I made a little comparison of opening a GeoTiff file. it Is only a small one (3000x1300 pixels), downloadable here. But you can see that reading has improved a lot between SNAP 6 and SNAP 7. Comparing SNAP 7 and the current dev version, there is no big improvement anymore. The videos below are ordered from top to bottom. SNAP_dev first, SNAP_7 and as last one SNAP 6.
However, the performance also depends on the specific file. With another file, you can get different results.
@marpet if you try what is described in S1TBX-651 you’ll notice that something is wrong in 7.0. Opening unprocessed S-1 images is fast but there’s an issue with processed ones.
It could also be that the writing causes the problem. By the way, in the issue it is not said which data format is used for the output. But I guess GeoTiff.
This could already be the difference.
Original S1 data is compressed and the output not. More data needs to be read which takes more time. But I’m just guessing. I think Luis is investigating this.
Yes Marco, because this an example of resample it runs without any error, but long time so far, more than one hour,
The bug in question only affects interactive viewing in the GUI, not gpt-processing. Falah are you saying SNAP6.0 was faster for that specific operation?
No, only the viewing as you mentioned, but according to
I only guess, but, the file data is GLCM sigma0, VH, VV, is big, it is proceeding now as you see, but long-time, But I found under windows os, if the system sleeps, the processing using gpt sleeps as well, I resit the setting to be never sleep, it takes long time but it works fine.
