Closed YangWaldon closed 1 year ago
Can you provide an English translation What happens if you are putting your graph outside of OneDrive
Just tested it Environment: logseq is currently up to date, Win10, OneDrive is running normally When I use logseq to open the main library in OneDrive that I've been using before, I get stuck when typing, and after closing logseq, it continues to use CPU and memory for a long time (even when OneDrive has finished syncing the files)
It should be noted that this problem only appeared after beta 076, and every version has this problem
Video recorded at the time of input https://user-images.githubusercontent.com/49675185/181203843-5159fac1-b138-42f6-a218-099ea50c0fa3.mp4
@YangWaldon Thank you for your translation. So what happens if you are putting your graph outside of OneDrive?
I just tried it, and after creating a new library in a non-OneDrive folder, logseq doesn't have the above two problems (input lag and closing continues to take system resources), but when I switch to a library in OneDrive, the above two problems appear again
Sounds like file watcher related. We will keep monitoring this.
Ok, thank you, the 076beta version is a watershed for this issue and I hope to get your reply here when the issue is resolved.Until then, I can only use the 076 beta. Thank you again
@YangWaldon To lock on the issue, more case to test: What if you copy your graph out of OneDrive and link it into Logseq?
I can copy the library from OneDrive to a non-OneDrive folder to test it, but what does the link back to logseq mean?
@YangWaldon It means adding the graph into Logseq :) Never mind
I just tried copying the library from OneDrive to other non-OneDrive folders and then loading this library in logseq, and I still have the above problem, the input lags and continues to use system resources after closing
@YangWaldon So it's not related to OneDrive. Would you mind sharing your graph to us, or providing some key information to reproduce the structure / queries you used? Also we want to know the plugins you are using. My email address is junyi@logseq.com
Given the private nature of personal notes, I'm sorry I can't share the entire library of notes with you, but what key information do you need and I'll see if I can provide it to you
@YangWaldon How many pages do you have? How big are they? What's the queries you used in the graph?
Also need to collect some info about your OS. What anti-virus software are you using? (Windows defender?)
My library is 973MB with 750 pages, to solve this problem I converted all the queries used in the library to code form before, so now my library doesn't use any queries
All the queries were converted manually into the following form
@YangWaldon The enclosed one seems like having an invalid usage of and
.
Nvm; will try to reproduce the issue.
@YangWaldon Are you using flashcards? How many cards are there? Ref: https://github.com/logseq/logseq/issues/4175#issuecomment-1197658696
There are currently 1220 flashcards
Sounds to be related to https://github.com/logseq/logseq/issues/6152
Does this mean that if you keep the number of flashcards down, you can avoid the performance problem?
@YangWaldon We are fixing the performance bug related to the card system.
@YangWaldon
Hi guys, thank you for the reporting, this should be addressed by #6105, hopefully, it'll be included in the next release.
https://github.com/logseq/logseq/issues/6152#issuecomment-1201478215
Is this fixed and included in Nightly Release 20220803, because I just tried Nightly Release 20220803 and the stuttering and memory hogging problem still exists after closing
So your issue is not related to the flash cards. Can you record a performance profile? Here's a tutorial from figma: https://help.figma.com/hc/en-us/articles/360041468414-Record-a-Chrome-Performance-Profile
I've been too busy to follow your instructions lately, but after updating to 080beta just now, the input lag is basically gone, and it doesn't continue to take up memory after turning off logseq, does this mean the problem is solved? How exactly was this resolved?
@YangWaldon I guess it was because of #6299. A corrupted SQLite DB blocks Logseq from closing and releasing its resource.
I just downloaded it today, and i found the same problem. I only created one folder to save, nothing else. After I close the window, it still there, with high CPU share.
@PGCharlesFC What's the version? Are you using Windows? Have you used the multi window feature?
@YangWaldon @cnrpman
I also encountered this problem. After I tried to run logseq in compatibility mode, the CPU occupation rate was normal!
@BaldStrong @PGCharlesFC We had some investigation on the Windows recently. It should be caused by the updater program. Re-opening Logseq could fix the behavior. Will fix it later.
@cnrpman after i upgrade it to 0.8.5, it seems normal
same in Mac. My machine is Mac with M1 chip, version is 0.8.7 CPU, GPU and memory utilization is very high, even in background, please fix it ASAP.
@xiongjy2104 Cannot observe. Does restarting app help?
This ticket is for the updater issue on Windows that already fixed on the previous version. Can you open another ticket with more details provide?
What happened?
刚才测试了一下 环境: logseq目前最新,win10 ,OneDrive正常运行 用logseq打开之前一直使用的处于OneDrive中的主库,输入的时候比较卡,将logseq关闭之后,会继续长期占用CPU和内存(即使是在OneDrive已经将文件同步完成的情况下)
需要说明的是076beta版之后才出现了这个问题,而且每个版本都有这个问题
Reproduce the Bug
如上所示
Expected Behavior
如上所示
Screenshots
输入的时候录制的视频 https://user-images.githubusercontent.com/49675185/181203843-5159fac1-b138-42f6-a218-099ea50c0fa3.mp4
Desktop Platform Information
No response
Mobile Platform Information
No response
Additional Context
No response