AsReference를 사용하여 속성을 정규화하여 총 550,000 개의 추가 5K를 면도하고 싶은지 여부를 결정해야합니다. 결국, 5K는 전체의 일부에 불과합니다. 1 % 미만입니다. 그래도 성능 저하가 미미한 경우 - 왜 안됩니까?AsReference 한정자를 사용할 때의 성능 저하는 얼마나 심각한가?
감사합니다. 실제로 공유 참조가있는 경우 AsReference 정말 크기를 줄여 사용
대한 설명
. 내 질문은 성능 또는 퉁명스럽게 넣어 - 속도.
분명히 모델에 따라 다르며 직렬화와 비 직렬화는 여기에서 달라집니다. 보통 크기의 모델의 경우 성능이 인 오버 헤드은 일반적으로 처리 할 실제 serialization이 적다는 점을 제외하고는 최소한입니다 (반복되는 객체 인스턴스가 AsReference으로 합당하다고 가정하고, 오버 헤드가 전혀없는 경우). 최소, 낭비이다). 그리고 참조가 큰 데이터 분기 (아마도 하위 모음 등)를 다시 직렬화하지 않는다면 우리는 CPU와 대역폭 모두에 대해 아주 좋은 절약을 얻을 수 있습니다.
문제가있는 부분은 이전에 객체를 본 적이 있는지 여부를 확인하기 때문에 여기의 비용은 순번으로입니다. deserialization하는 동안 인덱스를 사용하여 목록에서 뽑아내는 항목이므로 매우 빠릅니다.
DynamicType은으로 여기에서 을 사용할 수 없다고 가정합니다. 여기에는 또 다른 우려 사항이 있습니다 (다시, 영향은 최소화 됨).
재 저장; 현재 플랫 목록을 유지하고 참조 평등을 확인합니다. 해시 테이블/사전 조회를 사용하고 싶지만 GetHashCode()/Equals을 무시하는 유형에 대한 우려가 있으며 슬프게도 원래 object.GetHashCode() 인스턴스 메소드에 액세스 할 수 없습니다. 즉, 의 경우 매우 큰 숫자 인은 AsReference으로 표시되며 (그래프에서는 많은 수천 개의 개체를 의미 함) 천천히 저하 될 수 있습니다 (길이 N이 늘어나는 목록에서는 O (N)이됩니다). 이것을 해시 검색으로 변경하면 각 조회시 O (1)가됩니다.
우리는 큰 소리로 수 생각 가능성 (이 자체가 통증이 더 반사를 포함하더라도) 우리는 유형이 오버라이드 (override)하지 않음을 증명할 수있는, 또는 우리가 단지 사용자를하지 믿을 수있을 때 뭔가를 할 GetHashCode() 등의 엉망으로 만들고 평등의 정의를 그래프의 평등을 의미하도록 사용하십시오. 나는 여기에 생각이 열려 있지만, 현재 참조 평등이 가장 안전하고 간단한 옵션으로 사용됩니다.
실제 수치는 모델 및 크기에 따라 크게 다릅니다. 당신은 편리한 모델을 가지고 있고 AsReference없이 크기를 알고 있기 때문에 아마도 Stopwatch 또는 이와 비슷한 형태로 (아마도 MemoryStream과 비슷한 형태로 포장하기에 좋은 위치에있을 것입니다. 따라서 디스크/IO 비용을 타이밍에 포함시키지 않아야합니다) .
이 답변을 주셔서 감사합니다. – mark
@Marc, 직렬화 중에 플랫 목록에서 이미 발견 된 객체에 대해 O (N) 검색을 수행하는 대신 사전에 O (1) 검색을 수행 할 수 없었습니다
@Anders oh awesome; RuntimeHelpers.GetHashCode()는 위에 언급하지 않은 채 말했던 메서드입니다. 이를 통해 참조 동등한 해시 조회를 작성할 수 있습니다. –
http://stackoverflow.com/questions/6463460/how-do-i-enable-string-interning-in-protobuf-net –
저의 오래된 질문으로 안내해 주셔서 감사합니다. 나는 질문을 편집했다 - 명확한 설명을 추가했다. – mark
내 기쁨! ..... –