feat: improve MemOS performance across common workflows

[World-controller]

Pre-submission checklist | 提交前检查

• I have searched existing issues and this hasn't been mentioned before | 我已搜索现有问题，确认此问题尚未被提及
• I have read the project documentation and confirmed this issue doesn't already exist | 我已阅读项目文档并确认此问题尚未存在
• This issue is specific to MemOS and not a general software issue | 该问题是针对 MemOS 的，而不是一般软件问题

Problem Statement | 问题陈述

As a MemOS user, I want MemOS to have better overall performance across common usage scenarios.

Some MemOS workflows may become slow as memory data grows or as more operations are executed in a session. This can affect the experience when creating, updating, searching, retrieving, or managing memories.

Expected:
Improve overall runtime performance and responsiveness of MemOS.

No specific benchmark, dataset, target component, profiling result, priority workflow, or acceptance criterion is provided yet.

Willingness to Implement | 实现意愿

• I'm willing to implement this myself | 我愿意自己解决
• I would like someone else to implement this | 我希望其他人来解决

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 7d918e2ecbed9827
Working branch: feature/autodev-1945
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.

[Memtensor-AI]

🤔 AutoDev task 7d918e2ecbed9827 needs clarification to proceed:
The issue body explicitly states no benchmark, dataset, target component, profiling result, priority workflow, or acceptance criterion was provided. Please pick a direction so we can proceed safely:

1. Target workflow: which user-facing path should we prioritize — (a) search / retrieve (MOS.search → textual memory), (b) add / extract / ingest (MOS.add → mem_reader / extractor LLM), (c) update / delete / manage (CRUD on vec_db + graph_db), or (d) startup / config / cube registration?

2. Target component: should we stay strictly inside src/memos/memories/textual/ (low blast radius, matches the feat: improve MemOS performance #1926 precedent), or are vec_dbs/ / graph_dbs/ / mem_scheduler/ / mem_reader/ also in scope this round?

3. Acceptance criterion: what counts as "done"? Examples — "≥ 20% latency reduction on search hot path in a synthetic microbench", "no regression on existing unit tests + ≥ 1 measurable micro-optimization documented in design.md", or "specific user-reported scenario X reproduced and improved"?

4. Duplicate handling: PR feat: improve MemOS performance #1926 already applied the obvious wins (per-instance LRU embed cache, drop redundant sorted, model_validate) to GeneralTextMemory. Should we (a) extend the same pattern to TreeTextMemory / PreferenceTextMemory in this PR, (b) tackle a different module entirely, or (c) close as duplicate of feat: improve MemOS performance #1926?

5. Constraints to preserve: any API surface, public method signature, persisted-data format, or DB schema we must NOT change?
   Suggested default assumption: Default plan if no answer arrives (mirrors feat: improve MemOS performance #1926 outcome, smallest blast radius):

• Target workflow: search / retrieve hot path.
• Target component: stay inside src/memos/memories/textual/ only — specifically extend the feat: improve MemOS performance #1926 micro-optimization pattern to src/memos/memories/textual/tree.py (TreeTextMemory), since GeneralTextMemory was already covered by feat: improve MemOS performance #1926 and tree_text_memory was explicitly listed as a follow-up.
• Concrete changes (mirror feat: improve MemOS performance #1926):
  1. Per-instance OrderedDict-based LRU query→embedding cache (cap 256, no functools.lru_cache on bound methods to avoid holding self).
  2. Drop any redundant Python-side sorted(..., reverse=True) after vector_db.search (Qdrant already returns descending score order; validated in feat: improve MemOS performance #1926).
  3. Switch read-path TextualMemoryItem(**d) calls to TextualMemoryItem.model_validate(d).
• Out of scope: vec_dbs/, graph_dbs/, mem_scheduler/, mem_reader/, evaluation/, API surface, DB schema/migration, no new dependencies, no algorithmic rewrites.
• Acceptance: tests/memories/textual/test_tree.py adds cases for cache hit + search ordering preserved; full tests/memories/textual/ green; make format clean.

If the maintainer prefers to close #1945 as duplicate of #1926, that is also acceptable and we will not push code.
The suggested default is only used if a maintainer explicitly confirms it.
Please reply with one of the following commands (only issue author or repo collaborators):

• /autodev confirm yes — agree and continue with the suggested default assumption
• /autodev confirm no <additional info> — provide more details
• /autodev cancel — cancel this task
  If there is no reply within 24h, AutoDev will cancel this task using the same outcome as /autodev cancel. It will not continue with the suggested default automatically.

[World-controller]

/autodev cancel

[Memtensor-AI]

🛑 AutoDev task 7d918e2ecbed9827 has been cancelled.

Cancelled by: @World-controller
Status: CANCELLED

The cancellation reason is kept in the user's original /autodev cancel ... comment.