Token导航 LogoToken导航

Agent Skill · 待分类

performance-optimization(性能优化)

performance-optimization 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

performance-optimization 是待分类类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描已通过,按安装量在待分类类的 11,209 个 Skill 里排第 6,571。

总安装 441周安装 18GitHub Stars 33下载 141核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:performance-optimization(性能优化)
来源仓库:https://github.com/josiahsiegel/claude-plugin-marketplace
仓库路径:skills/performance-optimization
安装命令:
npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill performance-optimization
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill performance-optimization

这个 Skill 是做什么的

这个 Skill 的分类还没最终确定,用法以来源仓库的说明为准。

performance-optimization 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合整理项目状态和变更事项。适用于围绕仓库状态、代码变更或协作事项进行信息整理和决策支持。通过分析 GitHub 活动和协作流程提供项目进展和问题追踪能力。

安装前需确认权限范围和维护状态,注意可能涉及网络访问和文件操作。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/performance-optimization

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

performance-optimization 怎么安装?

在终端执行 npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill performan…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

performance-optimization 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

performance-optimization 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

performance-optimization 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

performance-optimization 用的人多吗?

公开数据是累计安装 441 次,近一周安装 18 次,下载 141 次,GitHub 33 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

performance-optimization 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理待分类类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

待分类类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
infsh-cli

infsh CLI · Codex、Claude

4,374,576382权限未标注未明确未收录
ai-video-generation

AI 视频生成 · Codex、Claude

4,313,376382调用外部服务未明确有提醒
lark-openapi-explorer

云雀 OpenAPI 浏览器 · Codex、Claude

2,064,1209,011需要联网未明确有提醒
lark-workflow-standup-report

Lark 工作流程站立报告 · Codex、Claude

2,041,6328,978需要联网未明确通过
use-my-browser

使用我的浏览器 · Codex、Claude

1,848,49140操作浏览器未明确未通过
performance-optimization

性能优化 · 本页

44133只读未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Performance Optimization

Overview

Power BI performance depends on data model design, DAX efficiency, visual configuration, and infrastructure. This skill covers diagnostic tools, optimization techniques, and best practices for achieving fast, responsive reports.

Diagnostic Tools

Performance Analyzer (Built-in)

Enable in Power BI Desktop: View > Performance Analyzer > Start recording

MetricMeaningAction if Slow
DAX queryTime to execute the DAXOptimize measure, check filter context
Visual displayTime to render the resultReduce data points, simplify visual
OtherMiscellaneous overheadUsually minor, ignore unless dominant

Workflow:

  1. Start recording
  2. Clear visual cache (click "Refresh visuals")
  3. Interact with the report (change slicers, navigate pages)
  4. Copy DAX query from slow visuals
  5. Paste into DAX Studio for deeper analysis

DAX Studio

Free external tool for deep DAX performance analysis:

Key features:

  • Execute DAX queries with timing
  • Server Timings: shows Storage Engine (SE) vs Formula Engine (FE) time
  • Query Plan: view logical and physical query plans
  • VertiPaq Analyzer: model size and compression analysis
  • All Queries trace: capture all queries sent by a report

Server Timings breakdown:

EngineWhat It DoesOptimization Target
Storage Engine (SE)Scans VertiPaq data, retrieves rowsReduce cardinality, columns scanned
Formula Engine (FE)Evaluates DAX formulasSimplify DAX, avoid nested iterators

Ideal ratio: SE should be 80-90% of total time. High FE % means DAX is doing too much computation.

Common DAX Studio workflow:

  1. Connect to Power BI Desktop (or XMLA endpoint)
  2. Enable Server Timings (Query > Server Timings)
  3. Paste the DAX query from Performance Analyzer
  4. Execute and analyze timing breakdown
  5. Look for:

- Many SE queries (indicates materialization issues) - CallbackDataID in SE queries (data sent to FE for processing -- avoid) - High FE time (DAX too complex) - Large SE row counts (too much data scanned)

VertiPaq Analyzer

Analyze model size and compression in DAX Studio: Advanced > View Metrics

MetricWhat to CheckTarget
Table size (bytes)Identify largest tablesReduce columns, remove unused
Column cardinalityHigh cardinality = poor compressionReduce distinct values, group rare values
Column sizeDisproportionately large columnsRemove or move to dimension
Dictionary sizeLarge string dictionariesShorten strings, use keys
Relationship sizeMemory for relationship mappingNormal, cannot optimize directly
Hierarchy sizeHidden auto date/time hierarchiesDisable auto date/time

Data Model Optimization

Column Optimization

TechniqueImpactHow
Remove unused columnsHighDelete columns not used in any visual, measure, or relationship
Reduce column cardinalityHighGroup rare values (bottom 5% into "Other")
Use integer keysHighReplace text foreign keys with integer surrogates
Split date/timeMediumSeparate DateTime into Date (date) and Time (time) columns
Round decimalsMediumRound to 2 decimal places instead of 15
Avoid calculated columnsMediumUse measures instead (query-time vs storage)
Disable auto date/timeMediumOptions > Data Load > uncheck
Remove text from factsHighMove descriptions to dimension tables

Relationship Optimization

  • Use single-direction cross-filtering (avoid bidirectional)
  • Enable "Assume Referential Integrity" for DirectQuery relationships
  • Remove unused or redundant relationships
  • Use integer key columns for relationships

Partition Strategy

For large tables, partition by date range:

  • Historical partitions (yearly/quarterly) -- refresh rarely
  • Recent partition (current month/week) -- refresh frequently
  • Use incremental refresh to automate partition management

DAX Optimization

High-Impact Patterns

Use variables to avoid repeated calculations:

// BAD: Calculates [Total Sales] three times
Margin % = DIVIDE([Total Sales] - [Total Cost], [Total Sales])

// GOOD: Single calculation, reuse via variable
Margin % =
VAR Sales = [Total Sales]
VAR Cost = [Total Cost]
RETURN DIVIDE(Sales - Cost, Sales)

Avoid FILTER with large tables in CALCULATE:

// BAD: Scans entire table
CALCULATE([Sales], FILTER(ALL(Products), Products[Category] = "Electronics"))

// GOOD: Column filter (optimized)
CALCULATE([Sales], Products[Category] = "Electronics")

Avoid nested iterators:

// BAD: O(n^2) complexity
SUMX(Products,
    SUMX(FILTER(Sales, Sales[ProductID] = Products[ProductID]),
        Sales[Amount]))

// GOOD: Use relationship + simple aggregation
SUMX(Products, [Total Sales])

Use DISTINCTCOUNT instead of COUNTROWS(DISTINCT(...)):

// BAD
COUNTROWS(DISTINCT(Sales[CustomerID]))

// GOOD
DISTINCTCOUNT(Sales[CustomerID])

Avoid FORMAT() in measures (returns text, kills sort):

// BAD: Returns text, cannot sort
MonthLabel = FORMAT([Date], "MMMM yyyy")

// GOOD: Use a pre-computed column in the Date table for display
// And a numeric sort column for ordering

Measure Complexity Guidelines

ComplexityAcceptable ForPerformance Concern
Simple aggregation (SUM, COUNT)Any visualNo
CALCULATE with column filterAny visualNo
Single iterator (SUMX)Most visualsWatch row count
CALCULATE with FILTER(table)Limited visualsYes, if table is large
Nested iteratorsAvoidYes, always
CALCULATE inside SUMXUse carefullyContext transition cost

Visual Optimization

Reduce Visual Count

ProblemImpactFix
20+ visuals on one pageEach visual sends DAX queryKeep to 8-12 visuals per page
Visuals with many data pointsLarge result setsUse Top N, aggregation
Many slicersEach slicer change re-queries all visualsUse "Apply" button

Query Reduction

Enable query reduction features:

  1. Report settings > Query reduction > Add Apply button to slicers -- users click "Apply" after all slicer changes
  2. Reduce number of queries sent by > Disable cross-highlighting by default -- reduces inter-visual queries

Conditional Formatting

Avoid complex DAX-based conditional formatting on large tables. Use simple column references or measures with limited computation.

Aggregations

Pre-aggregated tables that Power BI queries instead of the detail table:

Setup

  1. Create an aggregation table (Import) with pre-computed aggregates:
SELECT
    ProductCategory,
    CAST(OrderDate AS DATE) AS OrderDate,
    SUM(Amount) AS TotalAmount,
    COUNT(*) AS OrderCount
FROM Sales
GROUP BY ProductCategory, CAST(OrderDate AS DATE)
  1. In Power BI, set up aggregation mappings:

- Table > Manage aggregations - Map: TotalAmount summarization Sum to detail column Sales[Amount] - Map: OrderCount summarization Count to detail table Sales - Map: ProductCategory group-by to Sales[ProductCategory] - Map: OrderDate group-by to Sales[OrderDate]

  1. Hide the aggregation table from report view

Power BI automatically routes queries:

  • Queries at aggregation grain -> hit the small Import table (fast)
  • Queries at detail grain -> hit the DirectQuery detail table (slower but accurate)

Automatic Aggregations (Premium/Fabric)

Premium and Fabric capacities support automatic aggregation training:

  • System analyzes query patterns
  • Automatically creates and maintains agg tables
  • No manual configuration required
  • Enable in dataset settings

Composite Models

Mix Import and DirectQuery tables in one model:

TableStorage ModeWhy
Date dimensionImportSmall, used everywhere, fast
Product dimensionImportSmall, frequent filtering
Customer dimensionImport or DualMedium size
Sales factDirectQueryToo large for Import
Aggregation tableImportPre-computed summaries

Dual mode: Table exists as both Import and DirectQuery. Engine chooses based on query context:

  • If all tables in query are Import, uses Import mode (VertiPaq)
  • If any table requires DirectQuery, uses DirectQuery for dual tables too

Set storage mode: Model view > select table > Properties > Storage mode

Composite models with Direct Lake (2025 Preview):

  • Mix Direct Lake tables with Import tables in a single model
  • Direct Lake tables load from OneLake delta files; Import tables from traditional sources
  • Enables extending a Fabric lakehouse model with additional reference data
  • Monitor fallback behavior -- DL/SQL tables may fall back to DirectQuery under load

Direct Lake Performance

Direct Lake provides near-Import query speed without data duplication:

AspectGuidance
V-OrderEnable in Spark notebooks/pipelines for optimal Parquet read performance
Framing frequencySchedule frequent framing for near-real-time freshness (seconds cost)
Column countMinimize columns -- each column still consumes memory when paged in
GuardrailsMonitor file/row-group counts per table (varies by F-SKU capacity)
Fallback (DL/SQL)Set DirectLakeBehavior = DirectLakeOnly to block DQ fallback and force optimization
Fallback (DL/OL)No DQ fallback -- queries fail if data cannot be served; optimize model size
Memory pagingMax Memory is soft limit -- excess paging degrades performance
Calculated columnsSupported but may trigger DQ fallback on DL/SQL; test impact
Modeling perfDesktop 2025+ provides 50%+ improvement for live Direct Lake editing

Large Dataset Optimization (10GB+ Models)

TechniqueImpact
Remove unused columns aggressivelyHigh -- every column adds VertiPaq memory
Split DateTime into Date + TimeHigh -- reduces cardinality significantly
Use integer surrogate keysHigh -- 4-byte integers compress far better than text
Reduce decimal precisionMedium -- ROUND to 2 places
Implement aggregation tablesHigh -- 100x fewer rows for summary queries
Use incremental refresh with partitioningHigh -- only refresh changed partitions
Enable automatic aggregations (Premium/Fabric)Medium -- system optimizes query routing
Consider Direct Lake for Fabric dataHigh -- eliminates Import refresh entirely
Disable auto date/timeMedium -- removes hidden tables
Archive cold data to separate modelMedium -- reduce active model footprint

Power BI Desktop Performance Settings

SettingLocationRecommendation
Auto date/timeOptions > Data LoadDisable for production models
Background dataOptions > Data LoadEnable for faster development
Parallel loadingOptions > Data LoadEnable for multi-table models
DirectQuery query timeoutOptions > DirectQueryIncrease for slow sources (default 10 min)
Query reduction for slicersReport settingsEnable "Add Apply button"
Auto recoveryOptions > Data LoadEnable to prevent work loss
Report storage modeOptions > PreviewPBIR format for git-friendly development

Power BI Report Server Performance Tuning

Report Server has different performance characteristics from the cloud service:

AreaGuidance
CPUMost critical resource at peak load -- add cores first
Memory/RAMIncrease allocated memory for better query caching
StorageUse SSDs with high IOPS for the report server database
Database isolationHost report server DB on separate machine from PBIRS
Scale-outDeploy multiple PBIRS instances sharing one report server DB
Load balancingUse NLB or Azure Traffic Manager across instances
High availabilityPassive standby VM in another region for business continuity
CachingConfigure report execution caching for frequently viewed reports
Data source proximityPlace gateway/PBIRS close to data sources to reduce latency
Concurrent usersMonitor with performance counters; scale out at 50+ concurrent

Bookmark and Filter Optimization

ProblemSolution
Too many bookmarks loading dataUse report-level filters instead of bookmark-captured filters
Bookmarks causing full re-queryMinimize bookmark-captured visual states
Complex cross-page drillthroughUse drillthrough instead of bookmarks for page navigation
Slicer cascades on page loadSet default slicer values to reduce initial query count

Performance Checklist

Data Model

  • Star schema design (fact + dimension tables)
  • Auto date/time disabled
  • No unused columns
  • Integer keys for relationships
  • Single-direction cross-filtering
  • Text columns only in dimension tables
  • Calculated columns converted to measures where possible
  • High-cardinality columns addressed

DAX

  • Variables used for repeated expressions
  • No FILTER on large tables in CALCULATE
  • No nested iterators
  • DISTINCTCOUNT preferred over COUNTROWS(DISTINCT(...))
  • No FORMAT in measures used for sorting
  • Measures return numeric types (not text)

Visuals

  • 8-12 visuals per page maximum
  • Apply button on slicers
  • Top N applied on large tables
  • Cross-highlighting minimized for heavy pages
  • Conditional formatting uses simple expressions

Infrastructure

  • Correct capacity size for workload
  • Premium/Fabric for large models (>1GB)
  • Gateway optimized (sufficient RAM, SSD, close to data source)
  • Incremental refresh for large tables
  • Aggregations for DirectQuery heavy queries

Direct Lake (if applicable)

  • V-Order enabled on delta table writes
  • Framing scheduled at appropriate frequency
  • File/row-group counts within capacity guardrails
  • Fallback behavior configured and monitored
  • Calculated columns tested for fallback impact

Report Server (if applicable)

  • Report server DB isolated from PBIRS process
  • Sufficient CPU cores for peak concurrent users
  • SSD storage with high IOPS for DB
  • Report caching configured for popular reports
  • Scale-out with NLB if >50 concurrent users

Additional Resources

Reference Files

  • references/dax-studio-walkthrough.md -- Step-by-step DAX Studio analysis guide with query plan interpretation and latest DAX Studio features

平台分布

Codex

36.02%
按下载量换算51

Claude

31.72%
按下载量换算45

Cursor

18.5%
按下载量换算26

Gemini CLI

9.96%
按下载量换算14

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills