add performance section to entities table

[itamar-smirra-port]

User description

Description

add performance section to entities table with more explanations.

Updated docs pages

Please also include the path for the updated docs

• Catalog page (/customize-pages-dashboards-and-plugins/page/catalog-page#performance)

---

PR Type

Documentation

---

Description

• Restructured performance section with improved organization

• Added comprehensive performance tips and best practices

• Expanded explanations for initial filters effectiveness

• Added new subsection on calculation properties performance

• Enhanced guidance on excluded properties usage

---

Diagram Walkthrough

flowchart LR
  A["Performance Section"] --> B["Initial Filters"]
  A --> C["Excluded Properties"]
  A --> D["Calculation Properties"]
  B --> E["Dynamic Filters"]
  C --> F["Best Practices"]
  D --> G["Performance Impact Link"]

Loading

File Walkthrough

Relevant files

Documentation

catalog-page.md Enhance and reorganize performance documentation section  docs/customize-pages-dashboards-and-plugins/page/catalog-page.md Restructured "Initial filters" into a subsection under new "Performance" parent section Enhanced initial filters explanation with emphasis on effectiveness for reducing loading times Expanded "Excluded properties" section with detailed rationale and examples Added new "Calculation properties" subsection with performance considerations Improved hierarchy and organization of performance-related content +15/-5

---

[qodo-merge-pro]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Not applicable: This PR only updates documentation content and does not add or modify runtime logic that would impact audit trails; no actionable code to verify logging of critical actions is present in the diff. Referred Code ### Performance In some cases, an entities table may be very large, resulting in long loading times. There are few tips and best practices we can use to speed things up and improve the page loading times. #### Initial filters The most effective way for reducing loading times. You can define filters that resolve when Port queries the data (rather than after querying like the table filters). This will reduce the number of entities displayed in table which will improve loading times. To define such a filter, use the `Initial filters` field when creating a page: <img src='/img/software-catalog/pages/initialFiltersForm.png' width='50%' border='1px' /> <br/><br/> You can define any [supported rule](/search-and-query/#rules) in JSON format. Here is an example that will only display `Deployments` that were updated in the past month: ```json showLineNumbers [ { "property": "$updatedAt", "operator": "between", "value": { "preset": "lastMonth" } ... (clipped 22 lines)
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Docs only changes: The diff contains Markdown documentation text without identifiers or code constructs to assess naming conventions. Referred Code ### Performance In some cases, an entities table may be very large, resulting in long loading times. There are few tips and best practices we can use to speed things up and improve the page loading times. #### Initial filters The most effective way for reducing loading times. You can define filters that resolve when Port queries the data (rather than after querying like the table filters). This will reduce the number of entities displayed in table which will improve loading times. To define such a filter, use the `Initial filters` field when creating a page: <img src='/img/software-catalog/pages/initialFiltersForm.png' width='50%' border='1px' /> <br/><br/> You can define any [supported rule](/search-and-query/#rules) in JSON format. Here is an example that will only display `Deployments` that were updated in the past month: ```json showLineNumbers [ { "property": "$updatedAt", "operator": "between", "value": { "preset": "lastMonth" } ... (clipped 22 lines)
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: No executable code: Only documentation content was added; there are no new failure points or error handling logic to evaluate. Referred Code ### Performance In some cases, an entities table may be very large, resulting in long loading times. There are few tips and best practices we can use to speed things up and improve the page loading times. #### Initial filters The most effective way for reducing loading times. You can define filters that resolve when Port queries the data (rather than after querying like the table filters). This will reduce the number of entities displayed in table which will improve loading times. To define such a filter, use the `Initial filters` field when creating a page: <img src='/img/software-catalog/pages/initialFiltersForm.png' width='50%' border='1px' /> <br/><br/> You can define any [supported rule](/search-and-query/#rules) in JSON format. Here is an example that will only display `Deployments` that were updated in the past month: ```json showLineNumbers [ { "property": "$updatedAt", "operator": "between", "value": { "preset": "lastMonth" } ... (clipped 22 lines)
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: No inputs added: The changes are documentation-only and do not introduce input handling code to assess for validation or sanitization. Referred Code ### Performance In some cases, an entities table may be very large, resulting in long loading times. There are few tips and best practices we can use to speed things up and improve the page loading times. #### Initial filters The most effective way for reducing loading times. You can define filters that resolve when Port queries the data (rather than after querying like the table filters). This will reduce the number of entities displayed in table which will improve loading times. To define such a filter, use the `Initial filters` field when creating a page: <img src='/img/software-catalog/pages/initialFiltersForm.png' width='50%' border='1px' /> <br/><br/> You can define any [supported rule](/search-and-query/#rules) in JSON format. Here is an example that will only display `Deployments` that were updated in the past month: ```json showLineNumbers [ { "property": "$updatedAt", "operator": "between", "value": { "preset": "lastMonth" } ... (clipped 22 lines)
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	✅ Improve clarity and fix grammar Suggestion Impact: The commit rewrote the "Initial filters" introduction to a clear, grammatically correct sentence explaining initial filters reduce loading times and are resolved during query time, aligning with the suggestion's intent. code diff: +### Initial filters + +Initial filters are the most effective way to reduce loading times. You can define filters that resolve when Port queries the data (rather than after querying, like table filters), reducing the number of entities displayed in the table. Rewrite the introduction for the "Initial filters" section to fix a sentence fragment and improve clarity and grammar. docs/customize-pages-dashboards-and-plugins/page/catalog-page.md [191] -The most effective way for reducing loading times. You can define filters that resolve when Port queries the data (rather than after querying like the table filters). This will reduce the number of entities displayed in table which will improve loading times. +Defining initial filters is the most effective way to reduce loading times. These filters resolve when Port queries the data (unlike table filters, which are applied after querying). This reduces the number of entities displayed in the table, which in turn improves loading times. [Suggestion processed] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies a sentence fragment and awkward phrasing in the documentation, and the proposed change improves readability and grammatical correctness.	Low
	✅ Improve phrasing and fix grammar Suggestion Impact: The commit updated the "Excluded properties" text, correcting "showed" to "shown" and improving the phrasing of the examples, aligning with the suggestion. code diff: - -Another way to reduce loading times is to exclude undesired properties from an entities table when querying the data. When using this option, the new table will not contain columns for the excluded properties. We recommend excluding properties with no actual benefit when showed in the table - big object property, long array properties, etc. +### Excluded properties + +Another way to reduce loading times is to exclude undesired properties from an entities table when querying the data. When using this option, the new table will not contain columns for the excluded properties. + +We recommend excluding properties with no actual benefit when shown in the table, such as large object properties, long array properties, and other complex data types. Correct a grammatical error from "showed" to "shown" and improve the phrasing of examples in the "Excluded properties" section. docs/customize-pages-dashboards-and-plugins/page/catalog-page.md [217] -We recommend excluding properties with no actual benefit when showed in the table - big object property, long array properties, etc. +We recommend excluding properties with no actual benefit when shown in the table, for example, properties containing large objects, long arrays, etc. [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies a grammatical error (showed instead of shown) and improves the phrasing, making the documentation clearer and more professional.	Low
	✅ Improve conciseness and fix grammar Suggestion Impact: The commit rewrote the "Calculation properties" section to improve grammar and clarity, addressing the issues noted by the suggestion (adding articles, removing "and needed," and fixing parallel structure by using "excluding... or replacing"). code diff: -#### Calculation properties -While calculation properties have powerful functionality, in some cases they can have negative performance impact. If possible and needed, we recommend excluding them from the table or replace them entirely with regular properties. - -Learn more about [calculation properties performance](/build-your-software-catalog/customize-integrations/configure-data-model/setup-blueprint/properties/calculation-property/#performance-impact). +### Calculation properties + +While calculation properties provide powerful functionality, they can impact performance when used in blueprints that have many entities. To improve performance, consider excluding calculation properties from the table or replacing them with regular properties. + +To learn more about calculation properties performance, refer to the [calculation property](/build-your-software-catalog/customize-integrations/configure-data-model/setup-blueprint/properties/calculation-property/#performance-impact) page. Refine the "Calculation properties" text by fixing the parallel structure of the recommendation and removing the redundant phrase "and needed" for better clarity. docs/customize-pages-dashboards-and-plugins/page/catalog-page.md [224] -While calculation properties have powerful functionality, in some cases they can have negative performance impact. If possible and needed, we recommend excluding them from the table or replace them entirely with regular properties. +While calculation properties have powerful functionality, in some cases they can have a negative performance impact. If possible, we recommend excluding them from the table or replacing them entirely with regular properties. [Suggestion processed] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies and fixes a grammatical error in parallel structure (excluding... or replace) and improves conciseness by removing a redundant phrase.	Low
Update

[aws-amplify-eu-west-1]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-2956.d2ngvl90zqbob8.amplifyapp.com

[sivanel97]

Added some changes, looks great, let's merge it :)