We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
大家好,最近使用FlashDB时,遇到一个问题,由于在申请空间和写入完之后来判断是否需要进行一下GC,所以在程序里的任何调用fdb_kv_set_blob或者fdb_kv_set的地方,都有可能进行一次GC,这就要求所有使用KVDB的任务,都要留够一次GC所用到的栈空间,这对于资源较紧张的单片机来说不大友好,而且这样会使这个过程不可控,不知道它会什么时候运行,由于flash操作缓慢,它如果在高优先级任务中执行,那么还可能会影响到实时性。
我目前应用里是把所有自动GC都屏蔽掉了,然后又写了一个函数,放在一个周期任务中手动检查扇区剩余空间和剩余扇区来判断是否需要GC,这样会牺牲一些flash空间,因为手动调用没办法卡的那么合适,但是省了不少任务栈。
大家觉得这个问题是否是个问题?这么解决是否合适?
The text was updated successfully, but these errors were encountered:
最新版本的 GC 并不会全盘进行垃圾回收,基本只会回收 1 个扇区。只是一个扇区的擦写,是不是影响不大了呢?
Sorry, something went wrong.
请问GC时,大概会占用多少任务内存空间?
我也遇到了跟楼主一样的问题, 触发gc时 会占用大量的栈空间, 这会导致我只要调用到 set 的任务都需要预留很大栈空间, 这样非常浪费
No branches or pull requests
大家好,最近使用FlashDB时,遇到一个问题,由于在申请空间和写入完之后来判断是否需要进行一下GC,所以在程序里的任何调用fdb_kv_set_blob或者fdb_kv_set的地方,都有可能进行一次GC,这就要求所有使用KVDB的任务,都要留够一次GC所用到的栈空间,这对于资源较紧张的单片机来说不大友好,而且这样会使这个过程不可控,不知道它会什么时候运行,由于flash操作缓慢,它如果在高优先级任务中执行,那么还可能会影响到实时性。
我目前应用里是把所有自动GC都屏蔽掉了,然后又写了一个函数,放在一个周期任务中手动检查扇区剩余空间和剩余扇区来判断是否需要GC,这样会牺牲一些flash空间,因为手动调用没办法卡的那么合适,但是省了不少任务栈。
大家觉得这个问题是否是个问题?这么解决是否合适?
The text was updated successfully, but these errors were encountered: