Skip to main content
S
SarahPrice10-Marble
10-Marble
March 7, 2012
Question

Arbortext 6.0 M020 Speed Issues

  • March 7, 2012
  • 15 replies
  • 2683 views

We have just upgraded to Arbortext 6.0 M020 are having multiple speed issues. Whenever we try to print preview, publish or print a document with graphics it slows down to a snails pace and will lock up the workstation. We have some people running Print Composer and some on PE Server, same issues with speed. We have been in contact with PTC and made several configuration changes to PE to accomodate large document processing however speed is still an issue. We havemaxed out thememoryon all workstations. Still having problems. We are contemplating backing back down to 5.4 since this is a major set back in our production process. Has anyone else experienced these types of problems?


    15 replies

    Show previous replies
    P
    ptc-19080751-Visitor
    1-Visitor
    March 9, 2012
    This can be done in the FOSI with counters.

    <counter initial="0" style="arabic" enumid="Act">
    <counter initial="0" style="arabic" enumid="Bct">

    ...
    <att>
    <specval attname="Act" attloc="#FOSI" attval="#EQ#Bct">
    <charsubset>...</charsubset>
    </att>
    </e-i-c>


    Good luck!
    Suzanne Napoleon
    SuzanneNapoleon@FOSIexpert.com
    "WYSIWYG is last-century technology!"


    P
    ptc-19080751-Visitor
    1-Visitor
    March 9, 2012
    Strings also work (in 6.0):

    <counter initial="0" style="arabic" enumid="Act">
    <counter initial="0" style="arabic" enumid="Bct">

    <stringdecl textid="Act.txt" literal="">
    <stringdecl textid="Bct.txt" literal="">

    ...
    <e-i-c gi="...">
    <charlist inherit="1" charsubsetref="block">
    <enumerat increm="1" enumid="Act">
    <savetext textid="Act.txt" conrule="Act">
    <savetext textid="Bct.txt" conrule="Bct">
    ...
    <e-i-c gi="...">
    ...
    <att>
    <specval attname="Act.txt" attloc="#FOSI" attval="#GT#Bct.txt">
    <charsubset>...</charsubset>
    ...





    >----------
    P
    ptc-19080751-Visitor
    1-Visitor
    March 9, 2012
    Further testing confirmed my suspicion that comparing strings is not the same as comparing counters. In the following, which is based on my previous examples, the specval comparing strings incorrectly succeeds, while the specval comparing counters correctly fails.

    <enumerat increm="200" enumid="Act">
    <enumerat increm="1000" enumid="Bct">
    <savetext textid="Act.txt" conrule="Act">
    <savetext textid="Bct.txt" conrule="Bct">

    ...
    <att>
    <specval attname="Act.txt" attloc="#FOSI" attval="#GT#Bct.txt">
    <charsubset>...</charsubset>
    </att>

    <att><specval attname="Act" attloc="#FOSI" attval="#GT#Bct">
    <charsubset>...</charsubset>
    </att>


    Suzanne



    P
    ptc-19080751-Visitor
    1-Visitor
    March 9, 2012
    Thanks to everyone for their input. My condolences to those with performance and keeps issues -- there's little or nothing you can do in the FOSI to fix things.

    Suzanne


    P
    pchateil7-Bedrock
    7-Bedrock
    March 12, 2012

    We noticed that behaviour when one of our customers upgraded to 6.0.


    We were to lucky to have only a few <att> to modify.



    As for ACL, from 4.2 to 5.4, each version brought a net increase in speed. I hope 6.0 will continue that trend.



    Pierre Chateil
    LCI TechPub Sud-ouest
    France



    In Reply to Ed Benton:


    Suzanne,
    We also noticed that in 6.0 the logic in the FOSI seemed to behave differently. I can't remember specifics right now (we are still using 5.2) but I think I remember that we have some FOSI <att>s that check for the #NONE content of a text variable. In 5.2 if the text variable did not exist it was interpreted as content=#NONE. In 6.0 if the variable did not exist it was interpreted as having some sort of value which was not the same as #NONE so the <att> was returning a FALSE value. I am inferring this conclusion from the behavior and have not spent much more time analyzing it.
    Like I said, I am a bit fuzzy on the specifics but I think I have expressed it as accurately as I can.

    Terms & ConditionsCookie settingsAccessibility statement