This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
You know the scenario, you have to solve a newly identified business problem now. In fact, it needs to be completed yesterday. You throw something together that gets the job done. And done right. You're a hero.
As your source data grows, your module sags under the pressure. You never built it expecting that the source data would add 15 more columns. Some of them blobs.
Your once almighty module begins to crawl.
Your hero status is in jeopardy.
Five easy tips & tricks to increase the performance of your module (can be applied either proactively or retroactively)
Don't handle data you're not going to process. Place a SELECT tool immediately after your INPUT limiting your data stream to the fields that you are concerned with, do not check "*Unknown". Even if you are not currently limiting your data stream, adding this tool now could save you headaches down the road if the architecture of the INPUT is outside your control.
Don't process unneeded whitespace. Update the size of the string data types to be real-world, not the default. US state codes are a string(2), leaving it at V_String(254) is wasteful. You're saving space and processing time by explicitely stating the size, less work for the engine.
Don't handle data you're not going to process (again). Place a FILTER tool immediately after the SELECT reducing your data stream further.
Be number savvy. Use a FORMULA tool to convert strings to numbers if you'll be doing math on them downstream. Number datatypes are conservative with their space usage. Also, doing this all upfront makes for a cleaner canvas as you're not having to add FORMULA tools before a SUMMARIZE, for example. Disclaimer: some strings can be converted to other datatypes in a SELECT tool, caveat emptor.
No doodling. Remove BROWSE DATA and BROWSE MAP tools. Rendering that data can be expensive.