X18 - Slow Library

[JKEdmo]

Switched over to X18 and noticed I often get the blue spinny Windows "circle of lag" when I try to drag and drop a Library Browser item into my plan.  Don't remember this in X17.  Any fix for this?  I think this was brought up in a previous thread, but couldn't find it.

 

 

Thanks again,

 

Jim

Edited August 12 by JKEdmo
Image added

[Eric_S]

15 minutes ago, JKEdmo said:

Switched over to X18 and noticed I often get the blue spinny Windows "circle of lag" when I try to drag and drop a Library Browser item into my plan.  Don't remember this in X17.  Any fix for this?  I think this was brought up in a previous thread, but couldn't find it.

 

Hello Jim,

 

Something that may make a difference is if you have an antivirus program with real-time protection. Since Chief Architect Premier X18.exe is a new program, it may not be in the list of exclusions (whitelist), and you can try adding it, then restarting your computer.

 

Here are some other questions / things to experiment with:

 

Does it happen only for the first selection in a program session? This can take a lot longer as the library browser is initializing.

Are you using Project Management?

Does it happen the same for items from the core catalogs V.S. your user catalog?

Does it happen even with the preview panel hidden?

Is your current plan template particularly complicated?

Have you cleaned your Temp directory recently?

[Eric_S]

33 minutes ago, JKEdmo said:

 

 

It looks like I was responding to your post pre-edit. If searching is slow, here are some more troubleshooting options:

 

* Does turning off Include Web Results help? (the top-right icon)

* Is your System Library Database Folder on a slower / network drive?

[robdyck]

I'm noticing that everything is slow. And in the NVIDIA Control Panel, I can't add Chief X18 to the program list.

I had no speed issues with the Beta versions.

[DRAWCO]

I am having the same problem.

[GaryOhmer]

nvidia control panel states program does not support optimization

[DRAWZILLA]

lib. is also a bit slow for me. everything else is good. Non- managed mode

Edited August 16 by DRAWZILLA

[ChiefGalloway]

Upgraded this week, and it's a shame. Every startup - you have to wait for catalog update or whatever hell program is doing. You try to pick different material and library freezes for solid minute or two. And I am running two 990 series 4tb Nvme drives in raid with 14GBs transfer speed, and no, it is not any third party software fault. It worked for years, why breaking it? 

[para-CAD]

6 seconds to load to the dashboard

6 seconds to have a layout opened from the Recent Files list.
1 second to double click a layout "view port" and have the referenced plan file open to the saved plan view.

7 seconds to update the core catalog files


M4 Max MBP
macOS 27 Golden Gate Public Beta

[portrait]

Providing the relevant permissions for X18 in the antivirus software and turning off “Include Web Results” does improve the library search, but it is still considerably slower than X17.

It is slightly faster on my newer laptop running Windows 11 than on my 12-year-old Dell workstation (Win 10), but both are still slower than X17.

[KDsnyder]

I have one .layout open, one .plan open, two clay rendering views open. My model is a single story 500sf ADU with flat terrain and no landscape features.

 

I clicked a window to add a window treatment, clicked "library" in the "Blinds>style" drop down and I've had the spinning blue circle going on 5min at the time I hit reply to this message.

 

GPU is siting at 3-5%, CPU 2%, Memory 67%

 

In x17 this was the easiest task. Thinking of regressing but I've got work in x18 now and can't go back.

[Gawdzira]

I am dying here. I have spent the last 2 hours trying to come up with a solution to send a friggin elevation to layout. This is the crap we went through in version x1 and 2 with new versions. Why is this happening now?

[Eric_S]

On 8/26/2026 at 8:48 AM, portrait said:

Providing the relevant permissions for X18 in the antivirus software and turning off “Include Web Results” does improve the library search, but it is still considerably slower than X17.

It is slightly faster on my newer laptop running Windows 11 than on my 12-year-old Dell workstation (Win 10), but both are still slower than X17.

 

1 hour ago, KDsnyder said:

I have one .layout open, one .plan open, two clay rendering views open. My model is a single story 500sf ADU with flat terrain and no landscape features.

 

I clicked a window to add a window treatment, clicked "library" in the "Blinds>style" drop down and I've had the spinning blue circle going on 5min at the time I hit reply to this message.

 

GPU is siting at 3-5%, CPU 2%, Memory 67%

 

In x17 this was the easiest task. Thinking of regressing but I've got work in x18 now and can't go back.

 

On 8/22/2026 at 2:36 PM, ChiefGalloway said:

Upgraded this week, and it's a shame. Every startup - you have to wait for catalog update or whatever hell program is doing. You try to pick different material and library freezes for solid minute or two. And I am running two 990 series 4tb Nvme drives in raid with 14GBs transfer speed, and no, it is not any third party software fault. It worked for years, why breaking it? 

 

@portrait@KDsnyder@ChiefGalloway

Please try the troubleshooting I posted in my previous 2 posts on this topic and contact technical support.

 

There was a program update released this week that addressed some library performance issues. If you haven't already, please install it. Since then, we've only seen similar performance between the X17 and X18 Library Browser on our end -- but it's hard to capture all the differences between our setup and yours on this forum.

 

[DRAWCO]

It seems to be fixed with update.

[Renerabbitt]

Library and Asset Manager are EXTREMELY slow at deletion and import across all PC. Mac, not nearly as bad.
I have installed my libraries on at least 100 machines, and every single PC is unbearably slow even with the fastest hard drives on the market in RAID0
Ridiculous to wait sometimes up to 2 hours to delete/empty trash and the install a fresh library copy. Yes you read that right, 2 hours.
For my machine with striped sn8100's with 16000 sequential read, it still takes 30-40 minutes. Its stupid.
Just tried to delete assets from asset manager, 600 items took 10 minutes.stupid.
I am beyond frustrated with this in X18
Otherwise LOVE X18

[Renerabbitt]

WHAT WE ALREADY KNOW ABOUT X18 LIBRARY SLOWNESS

A few things about the X18 Library slowdown are already known from watching Chief’s actual disk activity during Library import and deletion.

A .calibz library is essentially an archive containing all of the Library assets — textures, images, etc. — along with an internal .calib SQLite database that Chief uses to identify and cross-reference the Library contents.

THE IMPORT PROCESS

During import, Chief does not stream those assets directly into Managed Resources.

It first unpacks the entire .calibz into a temporary directory, writing all of those image and texture files to disk in their normal form.

Chief then references the .calib database and processes those same files again into the encrypted Managed Resources structure used by the X17/X18 project-management system.

So for a large Library, we are effectively writing the asset data twice:

.calibz → TEMP → Managed Resources

That becomes especially painful with a Library containing thousands of items and many thousands of textures.

THE DELETION PROCESS IS JUST AS BAD

Deletion creates essentially the opposite problem.

Because Chief still has no proper Replace Existing or Overwrite Duplicates function when importing a Library, updating a custom Library while preserving links to things like Custom Toolbars often requires deleting the existing Library first.

When that Library is deleted, Chief again creates a temporary working directory and processes those assets into the Trash library within Managed Resources.

Then, in order to import the replacement Library without the old items continuing to exist as duplicates, the Trash has to be emptied — meaning Chief has to process all of that data yet again just to finally get rid of it.

So an update cycle can involve an enormous amount of unnecessary disk I/O:

Existing Managed Resources → TEMP → Trash

followed by another processing operation to permanently delete Trash, followed by:

New .calibz → TEMP → Managed Resources

For a large Library, that is an extraordinary amount of file activity simply to replace one version of a Library with another.

THE MIGRATED .INI FILE CAN MAKE IT EVEN WORSE

There is another major source of slowdown that may explain why some users experience this much more severely than others: the migrated Chief Architect .ini file.

If you have not completely removed the remnants of previous Chief installations, X18 can inherit the .ini configuration from earlier versions.

That file can contain historical Missing Resource search locations accumulated over years of using Chief.

Any time Chief reported a Missing Resource and you pointed it toward a top-level folder to search for that file, that search location could become part of your saved configuration.

Those paths can then continue migrating forward from version to version.

The result is that an X18 installation may still be searching through enormous directory trees that were added years ago — potentially drives, project folders, texture collections, old resource folders, backups, or other locations containing huge numbers of files — whenever Chief is trying to resolve resources.

In my case, deleting the carried-forward .ini file and allowing Chief to rebuild a clean one produced a drastic improvement in Library performance.

That also means two users with nearly identical computers and identical Libraries can potentially have very different performance depending on years of accumulated resource-search paths buried in their configuration.

SO THERE ARE REALLY TWO DIFFERENT PERFORMANCE PROBLEMS

1. The amount of unnecessary file I/O involved in the current Managed Resources, Library Import, Trash, and deletion workflow.

2. Legacy Missing Resource search paths migrating forward through the .ini file and causing Chief to search locations that may no longer have any reason to be involved.

THE FIRST OBVIOUS FIX: LET US OVERWRITE LIBRARY ITEMS

The obvious first fix on the Library side is something I have been asking for forever:

Give us the ability to Overwrite or Replace Existing Library Items during import.

That alone would eliminate much of this:

Delete → Trash → Empty Trash → Reimport

workflow.

It would also eliminate an enormous amount of frustration when maintaining custom Libraries that are already linked to things such as Custom Toolbars.

THE IMPORT ARCHITECTURE COULD ALSO BE MUCH MORE EFFICIENT

There also seems to be a significant opportunity to improve the import architecture itself.

From a developer standpoint, why does every texture need to be fully extracted into TEMP before being written into Managed Resources?

A more efficient pipeline could theoretically read the .calib SQLite database, determine the required destination records, and then stream each compressed asset directly out of the .calibz archive into the Managed Resources processing/encryption pipeline:

.calibz → Stream/Decompress → Hash/Validate/Encrypt → Managed Resources

The .calib SQLite database itself could be extracted independently, potentially even into memory, without first dumping every image and texture into a temporary folder.

That would eliminate one complete write/read cycle for every asset in the Library.

TRASH SHOULD NOT REQUIRE REPROCESSING THE ENTIRE LIBRARY

The same general principle could apply to deletion.

Moving an item to Trash should ideally be primarily a metadata/state operation whenever possible rather than physically reprocessing every associated texture through a temporary directory.

Then permanent deletion could simply remove assets that are no longer referenced by any active Library item.

Right now we are effectively doing substantial file processing to delete something, putting it into Trash, and then doing more processing when we finally delete it from Trash.

That is an incredibly cumbersome way to permanently remove a Library.

CHIEF SHOULD ALSO GIVE USERS CONTROL OVER OLD RESOURCE SEARCH PATHS

On the configuration side, Chief should reconsider carrying forward years of accumulated Missing Resource search locations indefinitely.

At minimum, users should have a clear way to review, remove, or reset those paths without having to discover that deleting an old .ini file dramatically improves performance.

THE BOTTOM LINE

I’m describing the implementation from the outside rather than knowing Chief’s source code, but the disk activity itself is observable.

When a Library update involves tens of millions of filesystem operations, and an old .ini configuration can additionally cause Chief to crawl enormous directory trees looking for Missing Resources, the answer cannot simply be:

“Libraries are large.”

There are multiple parts of the current Library and Managed Resources workflow that could be made substantially more efficient.


here is a chapter in my user manual to completely remove chief from your computer to reinstall new. Something that it doesnt mention, make sure to export your current library
https://renerabbitt.github.io/ppx18-manual/?chapter=completely-remove-chief-architect-x18-for-a-fresh-install

Edited August 29 by Renerabbitt

[Smn842]

@Renerabbitt   While its clear Chief has work to do on this area, given your workflow have you considered using a RAM disk or RAM file system for temporary files or specific symbolic links?

 

I've been using them for years for various intensive software development tasks (temporary compiled files etc), and have been using RAM Disk from SoftPerfect.  However they have recently released their new RAM File System which is even faster, plus has the great benefit of only allocating RAM as it needs it.   

 

Product link https://www.softperfect.com/products/ramfs/ and a comparison with their own standard RAM disk and a 990 Pro SSD:  https://www.softperfect.com/products/ramfs/benchmark/

 

I have no affiliation with those products, I am just a user of some SoftPerfect products over the years.

[Renerabbitt]

7 hours ago, Smn842 said:

RAM disk

Yes and a ram disk does very little in my tests when compared to the raid0 sn8100s. 

Plus you need 4 times the space of your managed resources which for me was originally 15gb. So a 60gb ramdisk. That's just to eliminate it as a bottleneck. 1x is the managed resources, 2x is the temp directories, 3x is any outside resource pool and 4x is the write directory. I had to write a symlink to capture the temp.directory since it's a unique directory name that chief creates every time you have some file I/o pulling from managed resources 

I have 128gb ram on my main machine so so did get to test it.

Then you're just limited by caching, bus speeds etc.

 It's still slow because of how many thousands of I/O it's going through, which is why I think the method needs revision. Macs system architecture is just setup better for sets of large incremental read writes so Macs over there having a blast while I'm stuck in the mud 

 

Edited August 30 by Renerabbitt

[Smn842]

21 minutes ago, Renerabbitt said:

Yes and a ram disk does very little in my tests when compared to the raid0 sn8100s. 

 

Have you tried the RAM file system which is faster than traditional RAM disks as per my post?  I've got raid0 990 Pros in one of my dev machines and the RAM file system made a significant improvement compared to RAM disk.   

 

I agree that CA hitting NTFS file systems hard is an issue (I've worked on software performance for many years and NTFS is great but large and numerous directories hurt performance) and that's also where a RAM file system improves things as its not NTFS over RAM, but a file system emulating many features of NTFS without the full overhead.

Edited August 30 by Smn842

[Renerabbitt]

1 hour ago, Smn842 said:

its not NTFS over RAM

Ah understood, thank you I'll give it a test when I'm back in the office mon

[para-CAD]

The rest of the users of chief architect are not going to invest in the time and training to figure out how to develop a RAM drive just to make the software faster.
 

It’s a very complex app, and those coders in Idaho or wherever they might be remotely are going to figure this out like they always do, and things will get better.

[Renerabbitt]

2 minutes ago, para-CAD said:

rest of the users of chief architect

He says from the comfort of his faster Mac 

[para-CAD]

Brother, I have been a fan of your fascination with technology since you were first on this site. I hope things continue to get better and faster from input from people like you and other tech whiz giants.

[Renerabbitt]

1 hour ago, para-CAD said:

Brother, I have been a fan of your fascination with technology since you were first on this site. I hope things continue to get better and faster from input from people like you and other tech whiz giants.

I hope you caught my ton of being a goof ball.

And thank you, dad was buying all kinds of gadgets for as long as I can remember. 

I don't think I've ever purchased something>NG that I didn't take apart... And am always amazed by the ingenuity of it all

[Smn842]

13 hours ago, Renerabbitt said:

Ah understood, thank you I'll give it a test when I'm back in the office mon

 

For reference, on a 14900K with 6400Mhz DDR5 (and a lot of background software) this is what I get with the RAM file system I mentioned:

 

This is similar large sequential, but much faster figures for the others than the RAM disk software I used before.