From: Jose M. de la R. T. <del...@gm...> - 2016-09-29 08:21:57
|
Thanks Sergey, I think that you should split that into different projects if it is really another project. If it is the same one, it make sense to add to the current one. But this would be a way to alleviate the current issue. We will let you know about any progress related this. Thanks a lot for sharing the project.sqlite database for further inspection. Cheers, Jose Miguel. On Thu, Sep 29, 2016 at 10:17 AM, Сергей Назаров <ser...@un...> wrote: > Dear Jose, Pablo, > > Here is the project file, I also attach settings file just in case. > Yes, the tree is really big, I simply add branches as soon is new data is > arriving. So, for future I would try to split the data into as many > projects as possible. > > Best, > Sergey > > 2016-09-28 11:23 GMT+02:00 Jose Miguel de la Rosa Trevin < > del...@gm...>: > >> Dear Serguey, >> >> As Pablo said, thanks for given us important feedback. Could you share >> you project.sqlite databaset with us? So we can perform some tests on it. >> It should work with this number of runs and this would be smother after we >> fix some refresh problems. >> >> Kind regards, >> Jose Miguel. >> >> >> On Wed, Sep 28, 2016 at 11:00 AM, Pablo <p.c...@gm...> wrote: >> >>> Wow! We certainly need to have your case in mind (589 runs) when testing >>> performance. >>> Collapsing some branches actually reduce "drawing time" but the whole >>> project is loaded which takes most of the time. >>> >>> Now I can't see any other workaround than deleting runs. If you want to >>> keep them all, another option could be to copy the project folder (watch >>> out for the disk space), and in the new project delete runs. >>> But I can understand this way you loose the whole picture of the project. >>> >>> I've added your case into our issue, and will discuss your case in our >>> next development meeting. >>> >>> :-( >>> >>> Pablo. >>> >>> >>> On 27/09/16 16:26, Сергей Назаров wrote: >>> >>> Dear Pablo, >>> >>> Thank you for a quick reply. Unfortunately, I don't have many protocols >>> running at the same time, usually from 1 to 3. But the project is huge, the >>> number of folders in Runs/ is 589. I keep most of branches collapsed, >>> hopefully it prevent them from loading. >>> >>> Best, >>> Sergey >>> >>> 2016-09-26 19:00 GMT+02:00 Pablo <p.c...@gm...>: >>> >>>> Dear Sergey, >>>> >>>> Thanks a lot for your feedback, this is very important for us to know >>>> important issues and also to give priority to new features. We are aware of >>>> some performance issues related with the metadata loading, which sometimes >>>> blocks the GUI, as you are describing. Is this happening to you when many >>>> protocols are in ‘running’ state? Or just when the project has many >>>> protocols? We are working to find a solution to this problem and make the >>>> processing with Scipion more effective, sorry for the inconveniences. >>>> >>>> All the best, >>>> Pablo >>>> Scipion team. >>>> >>>> >>>> >>>> On 26/09/16 15:52, Сергей Назаров wrote: >>>> >>>>> Dear Scipion Community, >>>>> >>>>> I constantly experience issue with loading metadata to my projects. >>>>> It can get really annoying, I wait sometimes almost a minute to be >>>>> able to adjust the description of a protocol, choose data (particles. >>>>> models etc.). I found this behavior both on local machines and on cluster >>>>> through ssh. While I can understand slow metadata loading through ssh, >>>>> especially for a big project with many protocols already executed, on local >>>>> machine this behavior appears after sometime after reboot. I don't know if >>>>> it starts after some threshold amount of protocols or not, but after >>>>> machine reboot everything runs nice and smooth for certain time and then >>>>> starts again. >>>>> I found one closed request on github concerning slow metadata, but >>>>> without any details. >>>>> Could you please advise me something about this issue? How to behave >>>>> when your project is on cluster and metadata is slow? I am not superuser, >>>>> so I am not able to reboot nodes everytime. >>>>> >>>>> Best, >>>>> Sergey Nazarov >>>>> Biozentrum Basel >>>>> >>>> >>>> >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> >>> _______________________________________________ >>> scipion-users mailing list >>> sci...@li... >>> https://lists.sourceforge.net/lists/listinfo/scipion-users >>> >>> >> > |