At times I make a zip of the KiCad Mac application/package here and have noticed that the “ratio” between the unzipped application file/package “Kicad.app” and the zipped version is quite large. Example: The unzipped file/package is about 6,6GB and the zipped file is 1,36GB. Just for the sake of it I did the same with a different application file/package of about the same size (this time Apple’s "Final Cut Pro.app) which is 6,11GB unzipped and 5,61GB zipped. Is it easy understandable to explain why this difference is like so, can it be explained for a person with no programming knowledge? Is it more “empty rows” in the KiCad code or why does this happen? I don’t know why the word optimisation pops up and may this if so lead to better functionality or better performance in the application? I know nothing about programming or coding, it’s just an observation followed by a few questions. Thanks.
Try these course notes:
KiCad has a lot of text files with a lot of redundancy, especially the 3D models. Binary files like executable programs have less redundancy.
Good explained! Didn’t know the libraries/3d files was included in KiCad.app. When I do “Show Package Contents” now I see it. Thanks – good to learn something new every day. Btw, KiCad is already pretty quick, at least on smaller or medium projects, have not yet tried it on more complex projects.
Open your schematic file and find there for example resistor symbol definitions or capacitor symbol definitions.
If you were trying to tell by phone to someone else it, you are able to tell the first one and for next you can say: Just copy previous one and make these few modifications, and for next the same and so on. It is what zip is doing.
I don’t know what is “Final Cut Pro.app”. What you packed are also text files? If so I would be very surprised.
I got even ‘better’ result zip-ping one my LibreOffice *.ods file. Unzipped - 119k, zipped - 117k.
I believe you can find LibreOffice file that zipped will be little bigger than not zipped, but after checking about 10 of them I always get at least 1k size reduction. So may be my believing has no basis.
Majority of the disk space is 3d models. The step file format is very inefficient.
The rest is few hundred megs for kicad executables and another few hundred megs for the footprint and symbol libraries. There’s not much fluff in there.
You are hopefully on a modern Mac with solid state storage. Generally this means accessing so many and large files is relatively instantaneous due to the nature of SSDs.
Storing these files compressed would actually be inefficient and each file would need to be decompressed every time it’s accessed and that incurs CPU penalties.
Back in the days of expensive storage, there was an extension (disk doubler?) that would compress data on the hard drive and decompress when the file was read. It worked pretty well, and did approximately double the capacity of the drive.
Of course, if the drive directory got messed up (which happened with alarming frequency), no drive recovery tool was able to retrieve the data, so it was basically “reformat and start over.”
No thanks.
Yes, 3Dogs, I remember that, it was crap all the way (of course) and good enough I never even tested it.
My first desktop PC had this and used the doubling claim to sell as a bigger disk than it had - cheating. The disk was a super slow too laptop device, which crippled the machines performance.
The doubling didn’t happen in practice.
BTW, the reason you can’t compress Libreoffice files much, if at all, is because they are already zip files.
$ file dvds.ods
dvds.ods: OpenDocument Spreadsheet
$ unzip -v dvds.ods
Archive: dvds.ods
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
46 Stored 46 0% 2024-12-09 09:20 8a396c85 mimetype
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/menubar/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/progressbar/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/popupmenu/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/accelerator/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/floater/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/statusbar/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/toolbar/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/toolpanel/
0 Stored 0 0% 2024-12-09 09:20 00000000 Configurations2/images/Bitmaps/
14623 Defl:N 2476 83% 2024-12-09 09:20 0e9502ca styles.xml
899 Defl:N 261 71% 2024-12-09 09:20 d268f7b4 manifest.rdf
30590 Defl:N 4002 87% 2024-12-09 09:20 6f2f9a8d content.xml
848 Defl:N 420 51% 2024-12-09 09:20 9f3dd7f6 meta.xml
10000 Defl:N 1495 85% 2024-12-09 09:20 fdd251fa settings.xml
30132 Stored 30132 0% 2024-12-09 09:20 53ced1d4 Thumbnails/thumbnail.png
1068 Defl:N 306 71% 2024-12-09 09:20 5180b46d META-INF/manifest.xml
-------- ------- --- -------
88206 39138 56% 17 files
Op: as others have said, kicad file formats have a lot of text. Text compresses very well.
Think about Morse code. The most commonly used letters are shorter. E is a single dot.
It’s not exactly the same, but near enough.
Open a *.kicad_whatever file and you can basically read it like HTML.
I may be presuming a bit here, but the reasons for doing it that way, are that it’s easier for a human to understand when they debug, modify, or create tools. Kicad is also an open project with zero interest in hiding.
This had drawbacks. Everything has pros and cons.
There’s likely a cost to convert the data to a database format when opened, and the file size is much larger.
These costs in the era of multicore, 4+ghz, multi-terabyte machines is minimal.
If you were using Windows, you could enable folder compression on the kicad folder to achieve effectively the same thing as zipping.
Mac may have a similar feature.
I know it. It is why I was searching among them file to be bigger after being zipped.
The main reason for this thread was actually to ask/see if “compressed” / or maybe I should have said “optimized” code (which I have no idea about if it’s possible) would make it possible to make KiCad a faster application.
This is a very general question that applies to all applications, not just KiCad. (So it’s not really a KiCad topic.) But in compilers optimising for speed and optimising for size sometimes work in concert, and sometimes work against each other. Then there are so many factors that one has no control over, like the graphics rendeirng system, the operating system calls, the instruction set architecture. So it’s simplistic to think that smaller packages mean faster execution. The greatest improvements usually come from better algorithms, which can require more space.
If you really want to delve into such matters, enroll in a computer science course on algorithms. There are even online offerings. And nobody will ask you to use git. 
TL;DR: On a practical level if you want to run your programs faster, buy a faster computer and more memory.
Yes. It would be faster to load, and write files if they were a load-directly-into-memory-database format. There is definitely some conversion process on load and save.
However it would be far more difficult to work with at a nuts and bolts level.
With the speeds of processors, and the abundance of space available, 99% of people wouldn’t notice this optimisation.
Compression… I guess maybe the devs might consider a generic zip of the existing formats in the future as an OPTION.
Eg *. Kicad_pcb might become *.kicad_pcbz similar to the way Google has kml and kmz. The latter is identical to the former once unzipped.
Again though, windows, and presumably Apple have transparent to the user file system compression if you enable it.
Frankly though, the devs undoubtedly have higher priorities. If this was on a list, it would be pretty close to the bottom.
I am fascinated how fast KiCad fills zones. With KiCad I learned to use zones during whole process of designing PCB. Before, when I was using Protel 3 I added zones as the last design step as filling them for even a simple PCB took over 10 seconds. This time grew exponentially if it happened to you to left GND via being not connected to other GND with track reaching more than 30 minutes when you forget to connect vias and had may be 20 of them.
I don’t see any moment when I think KiCad should be faster. The only time when probably users (not me) wait for KiCad is when it loads all libraries at the beginning. I am using only my own libraries and I don’t notice the time of loading them. I have never before compared the sizes. My file manager shows me that my footprints libraries size is 1,94M (KiCad 192,09MB), and symbols is 2,36MB (KiCad 221,13MB). So loading them takes probably 1/100 of time if I were using KiCad libraries.
Yea, KiCad has good performance in many aspects and many good functions! But how fast is fast enough? 
#1 Stability
#2 function
#3 maintainability
#4 usability
#5 performance to the point it isn’t a usability problem
#6 ui improvements
#7 performance optimisation to the nth degree
As someone who has written code professionally, though not on large complex applications, that’s how I’d rank importance.
People will use a stable program that works well for the task and the user even if it has slow functions.
Programmers will work on maintainable code that people enjoy or find useful.
All good points there! Talking about UI, is there any “Themes” functions/plugins made for it, to get a different graphical style (icons etc)?
If you have a new question please start a new topic if the subject has changed instead of making this an epic topic that pulls in everything. Setting topic timer to autoclose in 12 hours.
My apologies, thanks, no more questions here now and no new topic in this.