Highlighted

Slow Performance or XDP File size very large

pguerett

19-03-2009

There have been a few reports of people having slow performance in their forms (tyically for Dynamic forms) or file sizes of XDP files being very large.



These are the symptoms of a problem with cut and paste in Designer where a Process Instruction (PI) used to control how Designer displays a specific palette is repeated many many times. If you look in your XDP source and see this line repeated more than once then you have the issue:







The problem has been resolved by applying a style sheet to the XDP and removing the instruction (until now). A patch has been released that will fix the cut and paste issue as well as repair your templates when you open them in a designer with the patch applied.



Here is a blog entry that describes the patch as well as where to get it.



http://blogs.adobe.com/livecycle/2009/03/post.html

Replies

Highlighted

MaFd0n

16-04-2009

My XDP file grow up to 145mb before i decided to see what was actually happening.

It appears that the LvieCycle Designer ES program sometimes writes alot of redundant data... the same line millions of times over & over again.

I wrote this small java program which reduced the size up to 111KB !!!!!!!!!!!!!!!!!! (wow what a bug that must have been!!!)

Here's the sourcecode:

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;


public class MakeSmaller {
private static final String DELETE_STRING = "                           <?templateDesigner StyleID aped3?>";

public static void main(String... args) {
  BufferedReader br = null;
  BufferedWriter bw = null;
  try {
   br = new BufferedReader(new FileReader(args[0]));
   bw = new BufferedWriter(new BufferedWriter(new FileWriter(args[0] + ".small")));
  
   String line = null;
   boolean firstOccurence = true;
  
   while((line = br.readLine()) != null) {
    if (line.equals(DELETE_STRING)) {
     if (firstOccurence) {
      bw.write(line + "\n");
      firstOccurence = false;
     }
    } else {
     bw.write(line + "\n");
     firstOccurence = true;
    }
   }
  } catch (FileNotFoundException e) {
   e.printStackTrace();
  } catch (IOException e) {
   e.printStackTrace();
  } finally {
   if (br != null) {
    try {
     br.close();
    } catch (IOException e) {
     e.printStackTrace();
    }
   }
   if (bw != null) {
    try {
     bw.close();
    } catch (IOException e) {
     e.printStackTrace();
    }
   }
  }
}
}

File that gets generated is the same as the xdp file (same location) but gets the extension .small. Just in case something goes wrong the original file is NOT modified as you can see in the source code. And yes Designer REALLY wrote that line like a gazillion times in the .xdp file (shame on the programmers!!)

You can also see that i also write the first occurrence to the small file just in case its needed...

Highlighted

Han_Dao

10-06-2009

Hi,

I had the same problem and I have to go the XML Source to manually search and delete "aped3". Now I see you wrote a java program to clean it up which is very good to use but I am still new to Java programming and not sure how to apply your script to clean it up for the form. Could you please show me how to apply your java program to clean up those "aped3" codes.

Thanks,

Han Dao

Highlighted

pguerett

10-06-2009

I did not write a java program....I apply an XSLT to the xml file. I use java to apply that XSLT file. To accomplish that 1 use a 3rd party library which I do not have the rights to distribute.

I agree with Jono ...the latest version of Designer with SP2 installed will clean the files when you open them.

If you cannot upgrade then I can apply the XSLT and send you back the results.....or if you have a way to apply teh XSLT I can make the style sheet available to you.

Paul

Highlighted

MaFd0n

11-06-2009

Hey!

Depends if you have a java IDE like eg. eclipse or netbeans you most

likely can just create a new project add the .java source code which i

posted and run it.

If you don't have an IDE install you should, but you don't have to, you can

also just do it with the java JDK. Use java.exe to compile the .java source

code to a .class file then run it using the java.exe executable, I don't

know the commandline parameters of java.exe by heart so you will have to

search for those on the net. But as these parameters are thé most basic

commands of java.exe I'm sure you wont have to search longer than 2 minutes

in total

At this very moment I'm quite busy at work so I dont have the time to help

you any further. I'm sure I wrote the program so you can use it with

parameters:

java.exe myCompiledSourceCode.class c:\path\to\yourFile.xdp

otherwise, edit the source code and modify the static path to something like

this: private static String path = "c:\path\to\yourFile.xdp";

I hope this helped you, if not I will check my e-mail when I get home and

then I will have more time to help you further.

Kind regards,

Carl.

Highlighted

crisis_davis

11-06-2009

I have 8.2.1.4029.1.523496 installed - Acrobat Pro version 9.1.2.

I have found that the performance of Designer with large xdp files (dynamic forms) extremely slow - (opening, saving and editing Master Pages - can take about 15 mins to save an XDP of about 2Meg). - I have tried this on both Vista and XP with similar results.

The same xdp file opens with Designer 8.1 very quickly (less than 1 min).

I don't seem to have those repeating lines in the xdp so am looking for any suggestions to overcome this issue. Any ideas?

Highlighted

MaFd0n

07-07-2009

If you don't have repeating lines I'm guessing you use alot of embedded images. I don't know anything else which would increase your size that heavily.

As said before, please post your form if you require any further help.

Rui_Esteves

07-07-2009

We are developing a form that has it the 1.3Mb mark.

As yours, it doesn't have repeating lines and the embeded images count for 150Kb.

We made a few tests and, on-average, each subform we use (under the root element) takes almost 200Kb.

It might be a bit much, but we have not found any way to work around this issue. If you find one, post it here please.