ios – 访问文件属性与访问sqlite记录

ios – 访问文件属性与访问sqlite记录,第1张

概述在我们的一个应用程序中,我被要求记录上次修改的图像日期.这样我可以检查服务器是否已更改某个映像并相应地更新我的缓存. 我的第一种方法是访问文件属性并进行比较,但在线的一些地方提到了延迟方面的严重瓶颈. 我的第二选择是创建一个SQLite表来管理它. (使用fmdb) 我决定编写一个简单的延迟测试.在下一个测试中,我正在访问500个文件属性和500个sqlite记录: - (void)latency 在我们的一个应用程序中,我被要求记录上次修改的图像日期.这样我可以检查服务器是否已更改某个映像并相应地更新我的缓存.

我的第一种方法是访问文件属性并进行比较,但在线的一些地方提到了延迟方面的严重瓶颈.

我的第二选择是创建一个sqlite表来管理它. (使用fmdb)

我决定编写一个简单的延迟测试.在下一个测试中,我正在访问500个文件属性和500个sqlite记录:

- (voID)latencyTest{    NSMutableArray *arrayTest1 = [[NSMutableArray alloc]init];    NSMutableArray *arrayTest2 = [[NSMutableArray alloc]init];    FMResultSet *results = [_database executequery:@"SELECT * FROM `tb_media`"];    NSDateFormatter *formatter = [[NSDateFormatter alloc] init];    [formatter setDateFormat:@"dd-MM-yyyy HH:mm:ss:SSS"];    NSLog(@"Time1: %@",[formatter stringFromDate:[NSDate date]]);    int i=1;    while(i<501)    {        Nsstring *test = [Nsstring stringWithFormat:@"%@/_media/media/19/%d.jpg",_outputPath,i];        NSDictionary *attributes = [[NSfileManager defaultManager] attributesOfItemAtPath:test error:nil];        NSDate *dateX = [attributes fileModificationDate];        [arrayTest1 addobject:dateX];        i++;    }    NSLog(@"Time2: %@",[formatter stringFromDate:[NSDate date]]);    while([results next])    {                NSDate *myDate = [NSDate dateWithTimeIntervalSince1970:[results intForColumn:@"last_update"]];        [arrayTest2 addobject:myDate];    }    NSLog(@"Time3: %@",[formatter stringFromDate:[NSDate date]]);}

结果:

//iPhone 5 (Actual Device) 500 Pics    files Start:                 05-03-2014 09:31:20:375     files End & sqlite start:    05-03-2014 09:31:20:491     sqlite end:                  05-03-2014 09:31:20:507    files Start:                 05-03-2014 09:31:56:305     files End & sqlite start:    05-03-2014 09:31:56:421     sqlite end:                  05-03-2014 09:31:56:437    files Start:                 05-03-2014 09:32:19:053     files End & sqlite start:    05-03-2014 09:32:19:170     sqlite end:                  05-03-2014 09:32:19:187

如您所见,结果几乎相同.
我的问题是:

>我假设使用attributesOfItemAtPath一次访问一个文件
比sql花费更长的时间.我错过了什么吗?
> attributesOfItemAtPath是否真正访问文件或iOS
filesystem将所有属性保存在某种数据库中
容易接近?
>看到上述结果后,我决定选择
attributesOfItemAtPath方法.还有什么我不是
考虑传递sqlite?

解决方法 在讨论解决方案之前,您的评估策略存在某些问题.

1)您没有纳入NSLog和while循环所花费的时间. 75%的时间是由他们承担的
而您只想比较intForColumn和attributesOfItemAtPath.执行此 *** 作的正确方法是运行仪器Timer Profiler并比较检索单个记录的时间.

2)您已将FMDB用作文件管理器.内部FMDB序列化文件中的数据. FMDB / sql lite的核心在于其数据结构,特别是您根本没有使用过的索引.
因此,即使您比较记录所花费的时间,您将观察FMDB所花费的时间比文件管理器多,因为以特定格式序列化数据需要额外的开销.

3)通过对磁盘(硬盘驱动器)而不是堆的访问次数来比较X个记录的访问时间.您正在做的是在两种情况下都对数据存储进行堆访问.因此,您将无法看到任何差异.

这是否意味着文件管理器比FMDB更好,绝对不是!!
以下是几个原因:

FMDB只有在配置完成后才能正常运行.
FMDB的核心在于分页(缓存到堆)和索引两个方面.
让我一次向你解释一下.

1)假设您正在尝试访问100张图像的时间戳.每个图像有1000个时间戳.这意味着您必须对数据存储进行100 * 1000 = 100,000访问.
如果图像很小,那么filemanager会将文件加载到堆中,访问速度将比FMDB快,但如果没有足够的堆空间,应用程序将发出内存警告并从磁盘访问文件而不是缓存,这显然要慢得多.

所以它是一个二进制状态,要么全部来自堆,要么来自磁盘

FMDB优于此状态并根据可用堆空间检索部分记录.当您有大量记录时,这会使访问速度更快.

测试此场景的理想方法是为至少10,000个图像(不是时间戳)运行您的fumpntion latencyTest.这样,与总体时间相比,对数时间和迭代速度可以忽略不计.

2)索引结构,这可以追溯到sql lite的基础知识.您可能希望添加额外的属性调用作为对图像的访问次数,并在其上编制索引.这将大大提高人均力量. filemeanger不太可能.

我推荐的解决方案.
1)如果您的数据小于2 MB(图像加时间戳),请转到filemenager

2)如果数据是> 2MB用于Core Data / FMDB.

核心数据针对多线程环境进行了额外的性能调整,还有许多其他功能,如无缝集成加密.

总结

以上是内存溢出为你收集整理的ios – 访问文件属性与访问sqlite记录全部内容,希望文章能够帮你解决ios – 访问文件属性与访问sqlite记录所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/1099652.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-28
下一篇 2022-05-28

发表评论

登录后才能评论

评论列表(0条)

保存