I'm not sure if anyone is keeping tabs on this forum. I'll post anyway. I guess if I receive no answers, it will probably mean the project is heading for the defunct list.
I was wondering if anyone has noticed a performance problem with pcb. I have tried this on 3 or 4 versions already on a FC6 installation. In all cases, what I find is -
1. The Element Library window will not allow me to select the library (versions before 20080202) and will not list all the parts in the library. In 20080202, I find I cannot select the parts from the list in the right window and the system becomes unresponsive for extended periods of time.
2. Sometimes I can select the part and drag it to the board, but the system becomes unresponsive again. I can select a part from the menu instead and when I drop it on the pcb window, often the system will take a very long time to respond. Similarly with a lot of other other operations such as selecting the part later and dragging it and whatever else I tried (but cannot remember).
As I said, I've compiled and tested on several versions - 20070208p1, 20070912, 20080202. At first I found this problem with the yum installed version on FC6. I decided I would compile it myself. I also tried using lesstif on one of the versions and discovered the same performance issue. I even tried 3.0.95 which I believe is a completely separate track and performance was as problematic as the other versions.
I've use various versions of pcb over the last 2 or 3 years and never found a problem. I've not used the program in maybe 6 to 9 months and in the meantime installed FC6. It's too late for me now to go back to FC5.
I notice very little activity on the forum, and it made me wonder if pcb is not actively being worked on anymore, though I notice the latest version was only released a month or so ago. It would be a real shame if the project is abandoned. I've found it very good and its got a much better user interface than Osmond on OSX and kicad. Its a lot easier to learn and a person can become very productive in a matter of minutes.
While the forum here is dead. The PCB mailing lists are very much alive, as is PCB. Try the latest CVS.
Post your message to the geda-user list.
Not sure about your slowness issues. Sounds very strange.
How old is the computer?
Is PCB installed on a hard-disk, or network share?
Is it slow with a blank board?
Is the board you're experiencing slowness with complex?
Does it contain polygons?
PCB can be quite slow rendering complex boards with polygons.
Are you running a composited desktop evironment, like Compiz?
The last fast version was pcb-20050315, everything since the GTK port and hid conversion has been deathly slow, so I've stayed with that version with back porting a few fixes along the way.
In it's current form, PCB is usable for student projects that do not have more than a few hundred connections. Multilayer boards with ground/power planes and several thousand connection grind to a slow unusable death. Designs in between are just painfully slow, enough that it's worth using another tool.
I have more than 30 board designs at this point in pcb-20050315 that run very snappy on a 500MHz P3 with 256mb of memory under RH9, that take a half hour or more to load on a 2GHz P4 Xeon and 6GB of memory with all releases since. Some of these designs are FPGA array reconfigurable computing boards, others are embedded systems, others are specialized systems.
I've sent some of these to Harry and other PCB developers to demonstrate the point ... it's never really been fixed.
I've just stopped bug reporting it, as they never have fixed the problem in 3-1/2 years, so it's simply not worth the effort to bug report problems.
I've sent Peter a few "small" pcb-20050315 design fragments that only take 10-20 minutes to load and redraw in a current version of PCB. Enough to make the point that it's not a lack of fast hardware problem for realistic designs. I have a couple other "large" designs that take over two hours to load and redraw under a current version of PCB, that are I admit, a bit doggy (20-30 seconds) at times even under even pcb-20050315 on a relatively large 2GHz Xeon machine.
John, the difference post pcb-2005.... would probably be the polygon clipper. (Although the GTK port may have been before the clipper, and probably slowed rendering down a little). The polygon clipper is vital to being able to perform connectivity checking for a circuit with planes.
There is also a change in behaviour with newer versions of PCB (I don't like that it changed loading old designs), in that it will only keep the biggest non-islanded piece of a polygon you draw. This can break designs if you've got cut-up "planes" (copper fill really) on signal layers, but relied on the different cutup pieces for connectivity. (Perhaps less of an issue for multi-layer boards where the polygons are on plane layers).
This weekend I coded up some changes which kindof-reinstate the old behaviour, keeping all pieces of a clipped polygon, but performing island removal on them. (That is still very slow unfortunately)
An alternative to the GTK port is Lesstif, but is probably not going to be much faster (if at all) if clipping of polygons against planes is your problem.
There is a change I pushed in CVS recently which avoids un-necessary drawing when moving objects etc., that helps speed a bit, and I just committed a couple of optimisations to the code underlying the polygon clipper. I also have a couple of changes which are not tested enough to push out yet, including a cache of the "diced" polygons used to draw on screen (makes zooming / panning much snappier), and some optimisations to the line-intersection code.
I'd appreciate (for curiousities sake) if you could try the current CVS HEAD, and see if that improves anything at all. Then make a copy of the design, edit out all the Polygon() lines on the layers, and see if it is snappy again without polygons. (I suspect it will be).
I'm working to improve speed when I have chance. I have a plan to implement a faster line-intersection routine (the current one is known to be slow), and that ought to improve polygon performance - perhaps significantly.
My goal is to (keep it all working/ make it all work) in real time, but here is the possibility that we could separate the computation of "pouring" / island removal operations as a separate step, just like "o" for "optimise rats" is separate now.
If you have an example design which is particularly slow, please send it to me by private email. I can't promise anything will change, but it does give me something to profile aginst. My current profiling board is a design I did about A4 size, 2-sided, lots of components. It is _slow_ with current PCB. Both sides have copper fill around all the signal traces. Clipping speeds (actually load time) before mods: 28 seconds, after mods: 17 seconds.
As a side note, I'm running with OpenGL rendering (not yet pushed back into CVS). That seems to harm snappiness of small boards a little, but scales more gracefully to rendering large boards than the GTK renderer did. If you're interested in having a go at that, I can point you at the repository.
Log in to post a comment.