1、过滤表达式。试着对EXPRESSION 的端口进行评估。尝试在EXPRESSION 计算FILTER 控件所需要的结果（真/假）。复杂的过滤表达式会使MAPPING 变慢。表达式和条件在EXPRESSION 中的计算是最快的。其结果是：条件越多、越复杂，速度的降低就严重。把实际的表达式（无论复杂与否）放在作为FILTER 的输入流的EXPRESSION 控件中，计算出一个数值的标志：1 代表真、0 代表假，将这个结果输出到FILTER 中，你能够观察到这样的配置所带来的最大的性能。
2、去掉所有的“缺省”表达式。包括“ERROR(XXX)”在内的任何默认值都会降低运行速度，它会给MAPPING 中的每个数据元素带来不必要默认值的计算。唯一的例外就是你必须为一个特定的端口设定某个默认值，这种情况下也有另一个解决方法：在EXPRESSION中添加一个IIF(XXXX,DEFAULT VALUE XXXX)的变量。这样做总是比设定一个默认值的速度要快（如果是对于OUTPUT 端口来讲）。
3、变量端口比输出端口要慢，减少变量端口的使用。变量对“静态并且是状态相关”的情况是比较好的，但是会增加处理时间，因为对经过EXPRESSION 控件的每条记录都要进行分配/重新分配的操作。
4、在EXPRESSION 控件进行数据类型转换。直接将一个字符串映射为一个整数没有什么问题，反之亦然，但是，在EXPRESSION 中利用TO_INTEGER(XXXX)函数将字符串转换为整数或者将一个整数映射为另一个整数会更快一些。因为（在进行直接的转换时）PMSERVER 会被等待判断这个转换是否能够被进行，这样速度就被降低了。
5、去掉没有使用的端口。令人感到吃惊的是，没有使用的输出端口对于性能没有什么影响。这是一件好事。然而，一般来讲，删除那些在MAPPING 没有使用的端口（包括变量）是一个好习惯。不过，没有什么快速的方法来判定哪些是没有用处的端口。
6、字符串函数。很显然，字符串函数的使用对性能有影响，尤其是那些改变字符串的长度的函数，例如SUBSTRING,LTRIM,RTIME 等等。这些函数能够很大程度上的降低MAPPING 的运行速度，因为在这些函数的操作代价是很昂贵的（READER 进程要对内存进
行反复的分配和回收）。字符串函数对于ETL 来讲是十分重要，也是很必要的，我们不建议完全的杜绝他们的使用，只是建议把字符串函数用在那些十分必要的地方。对这个问题我们的优化建议是：在数据库的源中使用VARCHAR/VARCHAR2 的数据类型，或者在数据源的平面文件中使用不限定长度的字符串（尽可能的）。这样做有助于减少对输入数据的清理操作。如果数据源是数据库，在数据库中执行带有LTRIM/RTRIM 函数的SQL 语句会比在INFORMATICA 中进行同样的操作快多了。
7、IIF 函数的代价是不小的。如果有可能，通过重新设定逻辑来避免IIF 函数的使用。这不仅仅针对INFORMATICA，在任何的编程语言中，它的代价都是很高的。它在工具中引入了“决策”，也在逻辑中引入了多种可能的代码路径（从而增加了复杂度）。因此尽可能的避免的使用IIF 函数，而唯一可能替代IIF 函数的方法是在SQL 中使用ORACLE 的DECODE 函数。
8、TEST 表达式控件使得MAPPING 变慢。IS_SPACES 之类的表达式会减慢MAPPING的运行速度，因为这个数据合法性的表达式必须把整个字符串都扫描后才能发现是否是空格，同样的道理，IS_NUMBER 也必须检查整个字符串。只要有可能，在不需要进行转换前
的预先检查的情况下，这些表达式都应该被删除。但是要知道，不带检查的直接转换一个无效的表达式可能会是的整个转换失败。如果你必须对一个数字型的字符串进行检查，试着用IIF(<field> * 1 >= 0,<field>,NULL)，假如你不关心它是否是0 的话。一个字母在这个表达式中返回的是一个NULL 值。IIF 条件判断比IS_NUMBER 要快一些，因为IS_NUMBER 需要解析整个字符串，而乘法表达式速度自然就快了。
9、同时写入多个目标的速度很慢。通常MAPPING 会产生多个数据目标，有时会有多个数据源。这样的结果是更加花费时间，尽管第一眼看起来并不是这么回事儿。如果体系结构允许改变，同时用户也能够对MAPPING 进行调整，那么尝试着对体系结构进行修改：一个数据目标一个MAPPING 是基本的标准。一旦达到这个要求，调优就变得很容易。有时将MAPPING 减少到一个数据源一个数据目标的情况是更好的。但是，如果体系结构允许更多的模块化，一个目标一个MAPPING 就不是最佳的选择了。进一步讲，你可以继续分解，一个数据目标的一个操作使用一个MAPPING，例如INSERT 和UPDATE。这样做的话，当你对SESSION 和目标表本身进行调优的时候，就有更多的牌可出了。这样做本身也可以提高操作的并行性。
10、太多的AGGREGATOR 控件。如果你的MAPPING 包括多于一个的AGGREGATOR，SESSION 的运行有可能会非常非常的慢，除非CACHE 目录非常的快，并且硬件的寻找和访问数据的能力很强。即使是这样，在MAPPING 中的端到端（end-to-end）的放置AGGREGATOR 控件也至少会以两倍的因子来减慢SESSION 的运行。这是因为在INFORMATICA 中，所有的I/O 活动都是瓶颈。需要注意的是，INFORMATICA 的PM/PC产品从4.7X 版本后都没有采用并行处理的方式。换句话说，INFORMATICA 产品的内部代码没有将AGGREGATOR 作为线程来运行，也没有把I/O 操作以线程的方式来运行，因此一个STRUNG 进程就可以因为I/O 的原因成为整个MAPPING 运行的瓶颈。
11、减少LOOKUP 控件的个数。为什么呢？如果有LOOKUP 控件，在内存中会占用大量的缓冲，尤其是1.6/4.6 版本的产品。最终的结果是没有其他的内存用来供SESSION 的运行而使用。DTM 的读/写/转换进程也没有足够的内存来保证运行的效率。PC1.7 和PM4.7
版本通过在CACHE 满的时候把CACHE 内容写到磁盘上的方法解决了部分问题，但是还是会引起资源的争用，在上述情况下，只是把对CACHE 的争用转换成了对磁盘的争用。内存的争用比磁盘的争用问题要严重一些，因为如果只有很小的内存来查找记录的话，操作系统就会因为临时/交换空间的不足而变得不稳定，同时由于反复的需要查找记录，会引起系统的更加不稳定。