Select is S*L*O*W but not in Development
(1) By eKundl on 2020-04-19 01:11:40 [link] [source]
C# Windows Form, Windows 10. using Dapper DLL. a very small table, only 80 rows and about 10 columns. doing this query: Select * from House order by Territory,TSeq ASC. Territory is a string, TSeq is an Integer. on a windows Form in the program, i do the Select using Dapper. take the result set into a List, then write the rows to a ListView. In the /bin/Release/ folder, this loads the ListView immediately. using SQLiteStudio, this Select takes .07 seconds. however, when I copy the /bin/Release/ folder with the exact same exe/dlls/and DB, to a folder on the Cdrive or Ddrive, it takes about 5 seconds to populate the ListView. I've tried with and without all the PDB/xml/config files, and on different drives and folders.. it runs slow everywhere but in the /bin/Release folder. ??? maybe this is a C# forum question, but I can't see what the difference would be between the Release folder and some other folder. thanks for any comments... eric
(2.2) By Simon Slavin (slavin) on 2020-04-19 01:44:57 edited from 2.1 in reply to 1 [link] [source]
I agree with you that this is very unlikely to be a SQLite fault. It's more likely a problem with what your C and D drives really are. Check for …
- Folder and file protections.
- Antivirus program checking that your program is allowed to access those files.
- Antivirus programs scanning the database files every time they're accessed.
- Automatic backup programs backing up the files every time they're accessed.
Are your C or D folders actually on a server somewhere ? Have you tried plugging in a Flash drive or other external drive and putting the database on that ? Does it take more like 0.07 seconds or 5 seconds ?
(3) By eKundl on 2020-04-19 02:19:04 in reply to 2.2 [link] [source]
yeah, i guess I should move this to a C# forum. no AV or backup is running.. this is on my home Desktop PC.
i just created another solution with just the Form that is the problem... I get the same results... when run from the development folder, which is on my D: drive... it loads the 80 rows immediately. copy the development folder to any other folder... takes 5 seconds.
WAIT A MINUTE... i do have Malwarebytes running, and probably windows defender is running and I believe i have Malwarebytes set to exclude my Development folder... that might be IT !
thanks for bringing that up... i'll try to trun the AV off for a test.
(4) By eKundl on 2020-04-19 02:24:04 in reply to 2.2 [link] [source]
THAT WAS IT... excluded the folder from MalwareBytes.. loads immediately now..
thanks a lot.. i wasted hours trying to see what was wrong with the code. i can sleep tonight...
(5) By Simon Slavin (slavin) on 2020-04-19 08:15:48 in reply to 4 [link] [source]
I want to thank you for updating us, since someone else is probably going to have the same problem and we can mention Malwarebytes by name as something to check.
Glad you solved your problem.
(6) By Keith Medcalf (kmedcalf) on 2020-04-19 17:39:22 in reply to 5 [source]
This is how all anti-ransomware software works. It does not matter who wrote it, it all works the same way by instituting a default "go slow" on everything which would other do I/O "too fast". (Where the definition of "too fast" varies by each software makers opinion, but is usually IOPD (IO per day) rather than IOPS (IO per second)).
Unless you MANUALLY designate the program or directory as "not ransomware".
This is on the theory that:
- most people "live to click"
- the average computer user IQ is on par with their shoe size
- ransomware must do "lots of I/O really fast" be effective
- unlike TCP there is no "evil bit" in the PE header so there is no way to detect evil software
- it is easier to spend mucho dollaro on a fast computer and then even more money on software to make it go slow, than it is to engage the brain
The prevalence of ransomware and of software specifically designed to make everything "go slow" is an indicator of the overall success of these strategies.