Pages vs. blocks performance

Questions & Help
1

hello forum :dancer:

my current way of structuring stuff is
i create a [page] with Journal and give it a light description on the block i created it

e.g.

2025/01/29
· [[questions]] where i ask stuff

then i go to that page with C-k and create a bunch of blocks, treating the whole thing as sub-headers (that can have sub-headers inside them)

· cooking
  · breakfast
  · lunch
  · dinner
  · tea
· gardening
  · greenhouse
  · outdoors
· computer

and then i go back to Journal and use /Block Reference at the start of each block i create to reference stuff…

i feel this workflow possibly makes the graph-view useless (prove me wrong) but what i actually want to know is, will i run on performance issues after some time? or does Logseq loads blocks and sub-blocks references only when i expand them? i intend to add entries with images in some of them… or should i create these sub-headers as standalone pages if performance is a concern?

2

Welcome.

  • Your case smells what is known as premature optimization.
    • Generally this is a bad thing.
  • Your workflow is more important than your performance concerns.
    • This is the most important point in my whole post.
    • Time spent bothering about performance is time lost from actual work.
  • As more notes get added, the time will come that performance will suffer.
    • But this may be not in this life.
      • Cannot predict such things.
    • Or may be not before the database version comes to the rescue.
      • Planning for the database version seems more important than planning for markdown performance.
  • Whenever performance becomes a real issue, there are options:
    • collapsing some blocks
    • promoting some blocks into pages
    • moving some pages to other graphs
  • And yet your suggested approach is perfect for markown (*).
    • (*) Except for a single point: Where exactly to shift from pages to blocks.
    • Logseq is an outliner, so at some point should use multiple nested blocks.
      • But this point should not be as soon as possible.
      • A tree-like structure is:
        • good for some things (e.g. nesting notes)
        • bad for some other things (e.g. grouping topics)
    • Each case is different, but in your example I would:
      • make pages for all of cooking, gardening and computer
        • They are independent-enough to have a distance from each-other.
        • They deserve to appear in the Graph view.
          • Though this is not the primary reason.
      • leave the rest as blocks
        • For example, outdoors is not even a noun.
    • As about questions:
      • it shouldn’t be a proper page
      • it should be a tag or other property of proper pages
        • But in singular, i.e. question
1 Like
3

well, in my defense the garden/cook/computer bit was just an example… i just tried to open 1 of my 3 org files i use on Emacs (around 325,000 words) and it just shows my TODO list, rest Logseq says that “large blocks won’t be loaded to not slow down the app”

maybe i’m too deep down the Emacs hole to move :herb:

edit: tried to increase the limit but it’s basically impossible to edit anything, although the scrolling was smooth…

4
  • Logseq could have much better support for large blocks.
    • Reading and editing should have a better separation.
  • And yet large blocks defeat the benefits of using blocks.
    • Most large blocks can and should be broken into smaller ones.
      • Information (and thus also knowledge) is better managed in small chunks.
      • This helps with performance as well.
    • Any large block that cannot be conveniently broken, should probably be in its own file.
      • Like pdfs which are assets.
  • Mass migration between systems is rarely smooth.
    • Should be grateful that migration is possible at all.
    • It is advisable for a user to:
      • choose a relatively small but representative part of their information
      • copy it to the new system
        • May need to operate and update both systems for some time.
      • edit it to adapt it to the new system’s conventions
        • Ignoring this step questions the meaning of the migration.
      • experiment with a few alternative approaches
        • You cannot fully understand an approach, until you apply it in practice.
      • acquire precious experience during the process
        • You cannot properly assess an application, until you use it for real.
      • only then decide if and how to proceed with the actual migration
    • The bigger the migrated volume, the more useful the above process.
1 Like
5

so the time a page starts lagging to have its blocks edited, i’ll use block-to-page plugin to slice the stuff to perform better :slightly_smiling_face:

edit: or just start organizing everything as pages and linking them to form a logic that can be seem over the ‘Graph view’ :grimacing: