Speed of V6 varies with use?

[Gary Campbell]

Guys...
In another thread I mentioned the difference of expectations from those that are "cutters" on a CNC and those that use the cutlist features. Even tho V5.2 was not lightning quick, it seemed workable. V6 has made me gain about 15 lbs as I need to go out and make a sandwich between mouse clicks. I am not ruling out the fact that my system could use an upgrade to get better performance, but wanted to find out if one of you had a setup that actually worked better than mine, or if its "just the nature of the beast".

Below is a closet module that we cut for a local designer. This series also has a shelf unit and usually comes in multiples of 3 or 4. THere are often "transom" cabinets that are the same width and can vary in height from 2 to 3.5' in height. These cabinets get 1 3/4" custom 10 lite doors with mirrored glazing. You will note that I do not have the hinges mortised, the fillers placed beside the draw bank or the doors placed for display purpose. I do have dovetail drawers installed from NOCUT material as we will make these in house. I cut these from the batch and have never looked at them in a CL window.

Could a few of you D/L this cab and just bring in in and out of the DBE, CE, EB editor, etc.? I am looking to see if it brings your system to its knees also. How does the time to manipulate, save, modify, etc. compare to anything similar you design. Please note if you Export reports or send to CNC.
Thanks for your time,

Baker-Edwards Master-Draws EXPORT.hsf

(3.33 MiB) Downloaded 1804 times

[Kenneth Rychlik]

Gary, All of my job files end in a esj extension. I can't do anything with yours. Normally the hsf is just one cabinet.

It is just me again??

Kenneth

[Kenneth Rychlik]

Ok, so it was just one cabinet. 30 seconds to nest and 20 seconds for a twd file.

It does seem like quite a bit of time for just one cabinet.

V6.2 is supposed to help with the speed issue.

KR

[Nat Wheatley]

Gary,

It takes about 68 seconds on my computer to both resize, and regenerate your cabinet. I have a number of cabinets which are in line with this same time frame. It may not sound like a long time, but over the course of putting together a batch of cabinets, including editing certain features, or putting together a library, it turns into a sizeable amount of time. Add to this, the time involved in manually applying basic machining details, which seem like they could be applied automatically, and the cumulative time is almost prohibitive, at least for me.

I do hope that increased speed, and the ability to add basic machining patterns (metal drawers, knob/pull holes. leveler leg holes, suspension block patterns) are being considered.

Nat

[Gary Campbell]

Nat...
My "refresh" times are inline with yours. I have had a few PM's where users have shorter times. It doesnt seem to me that going into Const Settings or any editor, even if just to check existing values, should take over minute to return to a ready state.

I am hoping that this time burden isnt the cost of actually using eCabs to machine parts, rather than display cabinets or generate a cut list. Before I had used it, I would have guessed that since eCabs was developed by Thermwood, the development features and actions would have been biased towards machinability. Using a standard cabinet, and before my machine geometry is applied, eCabs smokes! Then, one by one, as I add PE cuts, shelf holes, blind dados, and lest I forget the machine killer, dovetail drawers, to a cabinet the app gets exponentially slower.

Kerry gave me a workaround for the dovetails, which I really only needed for display purposes once, that should speed refresh times up. Thanks all that responded.

[Kerry Fullington]

Nat,

Try something for me. Shut down Windows completely not a restart then start your computer, run eCabinets and try Gary's cabinet and see if the times aren't much shorter.
I find that the longer (and more aggressive) my sessions are in eCabinets it seems to get bogged down and only a complete shut down of windows helps.

Kerry

[Nat Wheatley]

Kerry,

I tried that and get the same time. Things definitely get slower and slower, when I get into working on cabinets for lengths of time. I too, find that powering down/up seems to 'reset' things.

Nat

[Kerry Fullington]

Gary, Nat,

Moving Gary's cabinet between editors goes pretty smooth (I think they have made some improvements so a cabinet doesn't have to regenerate with every editor) but I hadn't tried the re-size.
Re-sizing the cabinet I get similar results to Nat.
I performed an experiment and the dovetail drawer seem to be the culprit so if you don't need the dovetail info to cut don't show dovetails, use butt joints and insets to get your pieces the correct size.

On all these tests I opened the cabinet and re-sized the width to 48"

Gary's cabinet no changes 63 seconds to re-size
Cabinet with part editor cuts removed 51 seconds
Cabinet with the part editor cuts but dovetail drawers converted to my butt joint drawers 37 seconds
Cabinet with drawers changed and part editor cuts removed 26 seconds.

Even 26 seconds is a painfully long time to wait when you are trying to get a job finished.

eCabinets has the need for speed.

Kerry

[Gary Campbell]

Kerry...

I will change the drawer Const method to reflect an accurate cut list output and use inset butt joints. Which will help a little.

I dont really think that removing the PE cuts should even be considered as an option anymore than you would wish that removing the rendering abilities was your only viable option to reaching shorter design times. I am trying to find out if I build another workstation type computer (replace my mobo with a dual xeon server board) can I reduce my design times by being much more inline with the listed minimum specs. Up grading the OS to x64, doubling the ram and putting in a mega vid card did little to change regen times. It takes a minute and a half to load and "build" this when selected from the cabinet list. Add a dozen more editor checks and changes... it seems to take longer to check and send to a batch than the few sheets take to cut.

If these cabinets were being cut as house product, our specs would be set and all that is required would be a resize. Since they come from another shop & designer, many things change with each job.

Cabinets similar to this with a small number of large parts cut in around 8 minutes per sheet or less, even on our small machine. This speaks to the fact that eCabs may be a little slow, but if you actually use it to go to machine, the addition of cut geometries, holes, dados and PE cuts (all the real reasons to own a CNC) bogs down an awesome design program that was written by "The CNC Guys".

And the fact that no good can come from adding dovetails to a draw box. Does anyone actually use this feature? It almost seems like a contradiction in terms. Remember... this comes from a CNC convert with very traditional roots.

[Kenneth Rychlik]

Gary,

I can feel the ground shaking from you banging your head against the wall all the way to Texas. lol

I would hold up on that 20 thousand dollar pc till after they come out with build 2, of which I was told would be "soon"

Kenneth

[Kerry Fullington]

Gary,

I wasn't suggesting that you remove your part editor cuts to speed things up. I was just doing a test to see what was slowing things down and it seems that the dovetails were the culprit. If you are not cutting the dovetails on the router I would suggest removing them. The part editor cuts didn't seem to cause a lot of problems.
I don't think you are going to be able to gain much speed by adding hardware. I think this is going to be a software fix. It will get better with each new build but speed (or the lack of) is really an issue with eCabinets.
Kerry

[Gary Campbell]

Kerry...
I understand. I wasn't really suggesting that you lose your ability to output the renderings I can only be envious of. I was put in a postions of providing some actual scale drawings and was able to provide a CL view. If you thought this cabinet was a little slow, you should see how a room with 4 of them can bog a system down. I was really hoping to throw some hardware $ at it and "fix" something. I will wait with the rest of the "crew" for an improved version.

I did some testing regarding your earlier mentioned reboot method to gain speed. This also included setting page file to larger and smaller than system managed size and also selecting "no Paging file". I was not able to notice a difference with any configuration on my machine. Dont know if this is good or bad.

[Donald Thomson]

Having been a software developer for almost 18 years (mainframes, Unix, DOS, Windows) - before becoming a woodworker - the slowing of a machine over time when using an application was a sign of memory leaks in the program. As a program chugs along, it allocates and deallocates memory for internal use. If memory is allocated and not deallocated properly, it will start to eat computer memory and not return it to the OS. This in turn bogs down everything else running on the computer.

When running the Resource Monitor in Windows 7 64-bit, I've noticed with eCabs V5 that its memory use continues to go up and up over time as the program is running. Each time an operation is performed, resize, faceframe edit, PE, etc., memory usage goes up. When returning to the main CE I would assume that memory use would go back, or close, to what it was prior to doing these other operations taking into account that features added to a cabinet will use more memory. I've also noticed when I do a save, the memory use goes up and does not go back down. Each time I do a save it goes up and up. I can start a cabinet editing session and eCabs will be using around 250MB of memory. After a couple of editor operations it will be up around 400MB. After each save it will increase by 50MB to100MB each time. By the time I'm done working on a cabinet with all the edits and saves, I've had as much as 1GB of memory being used by eCabs.

Another issue is Windows is an interrupt based system. This means an application will be interrupted anytime Windows requires input or a response. The code that is written to handle that request needs to accomplish its task quickly and return control back to the OS ASAP. If an application starts executing a bunch of code and never takes a "breather" to find out if the OS is knocking on the door, then the user interface will start to slow down. You all know the hourglass.

The way we handled processing intensive applications was to spin off separate threads of code that did not require freezing the user interface. The separate thread of code could execute in the background and the user interface would still be responsive and wouldn't give the impression that the application had locked up. For super intensive processing, multiple threads could be spun off to handle different pieces of the task and when finished would wait to sync back up with the other threads. Once all the threads were complete one of the threads would indicate they were finished and the user interface would respond and show the user something was done.

This multi-threading has additional benefits, especially in today's world of multi-core processors. The OS is free to move threads of code to different processors where multiple threads could be running, literally, simultaneously. This type of processing produces incredible performance gains not only for applications but for the system as a whole. This makes the user experience much more positive.

With today's 64-bit environment and access to much more memory, the OS is no longer the bottleneck in application execution speed. The perception of an application running fast or slow is purely a matter of how efficiently the application code has been written. Throwing hardware at an inefficiently written application will not speed up the application. It will certainly help the computer as a whole and make efficiently written programs perform much better.

I have a hunch that some of the performance issues in eCabs also has to do with code modules that Thermwood licenses from other companies to use in eCabs. Hoops for one seems to be at best marginally stable. This is code Thermwoods is not in control of so they, and we, are at the mercy of these other companies developing efficient code.

I am really looking forward to the capabilities and features of V6 once the program makes efficient use of computer resources and really screams along.

[Rob Babcock]

I have a dual core machine that I am running eCabinets on, and I have noticed the following in Task Manager:

CPU usage is shown as 50%.
There are two CPU graphs shown next to this, and one of them will be at or near 0%, while the other is at or near 100%.

This means that eCabinets cannot both CPU's, even to put the thread for a separate module on the 2nd CPU...

Fixing this wouldn't help guys like Kerry, who creates miracle work with a P4 pentium, if his signature is up to date.

[Donald Thomson]

Hi Rob,

What you are seeing on the resource monitor is that eCabs is, in fact, a single threaded (serial executing) application. The OS cannot move a single threaded piece of code across multiple CPU's.

It is a very deliberate and conscientious coding methodology to get an application to be able to run across multiple CPU's by creating threads of code, independent of the main code thread, that can in fact be moved to a different CPU to execute. This is not a simple coding method. It takes a lot of planning and design to create synchronization points to pull this off.

Think of it as a manufacturing plant where multiple operations (threads) are going on simultaneously (parallel processing). At some point all the individual processes need to come back together to form a completed product. I worked for several years in the automobile assembly business and parallel processing is really present. However, at the end of the day, it all needs to result in a completed automobile ready for a customer.