You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

如何估算Kotlin中HashMap查找与List迭代的性能差异及索引构建时机

嵌套数据查找的性能估算与索引方案选择

我正在开发一个需将PDF文档映射到对应JSON数据文件的应用。在实现方案时,遇到了一个问题:如何估算搜索函数的预期性能?

假设我有一个嵌套数据结构,需要为每个传入PDF找到匹配特定参数的数据对象。现有两种方案:

  • 直接使用原始数据,逐层迭代至找到匹配项
  • 将数据转换为HashMap这类索引结构,以匹配字段为键,通过键直接定位目标对象

第一种方案单次查找的平均耗时更长;第二种方案单次查找效率更高,但需预先遍历全量数据构建映射,存在初始开销。

我知道具体答案取决于数据集规模、嵌套深度及搜索次数,但希望能粗略估算哪种方案更适配当前场景。是否有技术方法或经验法则可以判断何时值得承担初始开销构建索引结构?

数据类结构示例

internal data class Idoc(
    @SerializedName("FileId") val fileId: String,
    @SerializedName("Student") val students: List<Student>
)

internal data class Student(
    @SerializedName("Id") val id: String,
    @SerializedName("SchoolId") val schoolId: String,
    @SerializedName("Name") val name: String,
    @SerializedName("Documents") val documents: List<Document>
)

// 注:尽管owners被定义为列表,但每个Document只会有一个Owner
internal data class Document(
    @SerializedName("Year") val documentYear: String,
    @SerializedName("Code") val imageCode: String,
    @SerializedName("DocumentOwner") val owners: List<DocumentOwner>,
)

internal data class DocumentOwner(
    @SerializedName("FirstName") val firstName: String,
    @SerializedName("LastName") val lastName: String,
    @SerializedName("OwnerType") val type: String
)

原始查找函数实现

// 根据学生ID、文档图片编码、所有者类型查找对应文档
internal fun lookupDocument(
    idocs: List<ServiceDocument>,
    id: String,
    imageCode: String,
    owner: IdocsDocumentOwner
): ServiceDocument.Document {
    return idocs.asSequence()
        .flatMap { doc -> doc.idoc.students }
        .first { student -> student.cbfId == id }
        .documents.asSequence()
        .first { doc -> 
            doc.imageCode == imageCode && doc.owners.first().type == owner.ownerType 
        }
}

内容的提问来源于stack exchange,提问作者pbuchheit

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.06.20 11:22:38