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 的爭用轉換成了對磁盤的爭用。內存的爭用比磁盤的爭用問題要嚴重一些，因爲如果只有很小的內存來查找記錄的話，操作系統就會因爲臨時/交換空間的不足而變得不穩定，同時由於反覆的需要查找記錄，會引起系統的更加不穩定。