I never assumed that I am reading all the data nor that I have only one 
table. I only said that if you have 100 match for a query (you can have 
thousands of rows in your table. That is the point of having a DB, handling 
multiple objects not just one or two) then you would have to read 100 
files. Disk fragmentation on an SSD, on the contrary to HDD, is not an 
issue and actually do not really exist (the SSD can acess each cell with 
the same access speed, it do not depend on the physical distance of the 
previously accessed cell) especially since all SSD now use Trim. So you are 
wrong again here. As for the DB indexes they are put into memory but the 
amount it takes into memory do not depend on the size of the records but 
only on their number (and the number of indexed columns) so here again you 
have no penality at inserting large objects into a DB if this data 
(=column) is not indexed  

On Thursday, April 4, 2019 at 6:28:59 AM UTC+2, Shai Almog wrote:
> Several things here aren't true. 
> First this assumes you are always reading all the data, if that was the 
> case then why have an SQL database in the first place. It also assumes only 
> one table and other tables aren't impacted.
> The second mistake is that randomly seeking through a large file is free 
> if you have an index. This isn't true. It's true that it's MUCH faster than 
> it was in the days of spinning platters but it's far from free and very 
> costly on a mobile device. A memory mapped file would need caching both in 
> RAM and in CPU caches. Both of these are limited resources that would cause 
> thrashing to flash storage when depleted. Every time you change something 
> in that large file you trigger disk fragmentation which has a lot of impact 
> on an SSD in terms of performance. Yes modern filesystems are better at 
> handling this but writing to a single large file is still way more 
> expensive. 
> The problem is that these will impact all your queries for the other 
> tables as well. RAM and CPU cache utilization is far more noticeable on 
> devices than on the desktop where the differences might not be noticeable. 
> We'd need to detect the various types of arguments that are submitted and 
> convert them to native calls for iOS. Passing arrays and other arbitrary 
> objects to the C layer in the iOS port is painful so no one got around to 
> do it for years. As I said, the demand for this was low and our resources 
> are low as well.

You received this message because you are subscribed to the Google Groups 
"CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to codenameone-discussions+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to