Trados Business Manager
Speech to Text
Managed Translation - Enterprise
Translation Management Connectors
Language Weaver Connectors
Language Weaver Edge
Tridion Docs Developers
RWS User Experience
RWS Community Internal Group
RWS Access Customer Portal
RWS Professional Services
RWS Training & Certification
RWS Enterprise Technology Partners
Trados Academic Partners
Trados Approved Trainers
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic Tridion Docs User Group
Tridion Docs Europe & APAC User Group
Tridion UK Meetup
Tridion User Group Benelux
Tridion User Group New England
Tridion User Group Ohio Valley
Tridion West Coast User Group
WorldServer User Group
Trados GroupShare Ideas
Trados Studio Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
RWS Language Cloud TMS Ideas
RWS Language Cloud Terminology Ideas
RWS Language Cloud Online Editor Ideas
Managed Translation - Enterprise Ideas
Tridion Docs Ideas
Tridion Sites Ideas
LiveContent S1000D Ideas
Events & Webinars
To RWS Documentation
To RWS Support
Detecting language please wait for.......
Actually I have a huge document (Approx 500 pages document) and it is taking approx. 2 minutes to load the whole cycle of transformation tables. Is there anyway to reduce the timing for the whole load cycle of transformation tables. Please note, the input I am using is XML.
Without seeing the data and the xychange tables, its difficult to provide any advice. However, usually the biggest performance hits in xychange are when there is a * wildcard at the beginning of a rule…
Without seeing the data and the xychange tables, its difficult to provide any advice. However, usually the biggest performance hits in xychange are when there is a * wildcard at the beginning of a rule. Another hit can be when using reinput.
For this group to provide help, you need to show examples of what you're trying to do with xychange - and better yet, explain why you're using xychange with XML. If its just character replacement then xychange should be faster than XSLT or similar. But if you're moving attributes and/or elements around then XSLT would probably be faster/easier/better.
PS For those that knew Larry Liebson's mantra: I didn't say it was cheaper - so "Liebson's Law of 'pick 2'" still holds true.
For XyChange to be taking 2 minutes on a 500 page file (not that huge, we do 3,500 page files regularly) there are I suspect a lot of wildcards. Making sure the wildcard searches are limited to a sensible number of characters to sear ahead (*[A-Z;1,12] rather than *[A-Z]) may help but I suspect it may also be worth looking at XSLT or Perl as an alternative.
Thanks Mark and Chris for the quick response.