응용 프로그램을 시작할 때 모든 것을 메모리에로드해야합니까?

VB.Net을 사용하고 있으며 상당히 신속하게 필터링 할 수있는 데이터 집합이 있습니다. 기본적으로 프로그램은 Google sugest와 유사하지만 드롭 다운 메뉴 대신 목록 상자를 사용합니다. 사용자가 단어를 입력하면 LINQ를 사용하여 단어를 비교하고 사용자 입력을 포함하는 단어를 필터링합니다. 데이터는 가변 길이 (0에서 200 자, 대부분 150 자의 문자)의 모든 문자열이며이 문자열의 수가 24 만 이상이며 계산은 XML 파일에 저장되어 있습니다.응용 프로그램을 시작할 때 모든 것을 메모리에로드해야합니까?

내 동료는 VB.Net의 XML 시리얼 라이저와 문자열/객체 모음을 사용하여 메모리에로드하는 것은 실용적이지 않으며 프로그램의 '시작'시간을 늦출 것이라고 말했습니다. 나는 프로그램을 아직 완성하지 않았고이 길을 계속하는 것에 대한 두 번째 생각을 갖고있다.

내 질문은 : 문제에 대한 현재 접근법 (시작시 메모리에 모든 것을로드하는)을 계속해야합니까, 아니면 내 딜레마를 해결하는 더 좋은 방법이 있습니까?

출처

2009-10-09 GaiusSensei

시작 시간을 방지하고 메모리에 유지하는 것이 성능에 영향을주지 않으려면 비동기 적으로로드하십시오. XML에서 240.000+ 문자열을로드하고 메모리에 유지하는 것이 가장 좋은 생각 인 것처럼 들리지만. 아마도 데이터베이스가 더 나은 접근 방법 일 것입니다. 또는 구문 분석이 더 빨라진 JSON과 같은 최소한의 형식.

출처

2009-10-09 22:32:44

+1을 사용하는 경우. 또한, 이것은 .NET의'BackgroundWorker' 구성 요소에 대한 훌륭한 후보입니다 - 정말 비동기로 수행되어야합니다. –

비동기 일을하는 것은 과대 평가 될 수 있습니다. 전체 데이터 세트가로드되어 검색 가능할 때까지 사용자가 애플리케이션으로 할 수있는 것이 아무것도 없다면 비동기 적으로로드하는 것은 무의미합니다. 데이터베이스는 좋은 생각이다. – MusiGenesis

@MusiGenesis 물론 그 시나리오라면. 그러나 중간에 페이지가 있거나 다른 특정 작업을 수행해야하는 경우 (특정 필드로 이동하기 전에 다른 필드를 채우는 것과 같이) 사용자가 앱로드를 기다리는 시작 화면을 보지 못하도록합니다. –

사물의 수에 따라 달라집니다 :

If 
((you know the strings will not hugely increase in number) && 
(you know the spec of the machines that will run your app) && 
(you are able to test that the load time is *good enough* on the above spec)) 
{ 
**don't bother changing approach.** 
} 
else 
{ 
**change approach.** 
}

다른 접근법은 분명히 비동기 게으른 부하의 일종이다.

출처

2009-10-09 22:34:43 JohnIdol

-1 (가상), Snake Plissken 아바타 용입니다. – MusiGenesis

나는 당신이 팬이 아니라고 생각합니다 :) – JohnIdol

대략 36MB의 문자열을로드하는 것에 대해 이야기하고 있습니다. 이것은 어떤 수단으로도 엄청난 양은 아니지만 (직접 XML을 읽는 것이 더 빠를 수는 있지만 ... 성능에 대해 걱정할 경우 직렬화 엔진을 사용하지 않을 것입니다.) 또한 사소한 양입니다. . Mircea가 제안한대로 비동기 적으로 수행하지 않는다고 가정 할 때 시작 시간을 몇 초 더 추가 할 수 있습니다.

비동기 적으로 수행하는 경우 데이터를 사용하는 UI 프로세스가로드 된 후에야 해당 프로세스가 실행되는지 확인해야합니다. 이를 보장하는 것이 어려울 수 있습니다.

출처

2009-10-09 22:36:22

앱을 시작할 때 메모리에 XML을로드하는 것은 좋지 않을 수 있습니다. 하지만이 길을가는 경우 BackgroundWorker 스레드를 사용합니다. 아이디어는 비동기 적으로 XML을 메모리에로드하는 것이므로 UI가 여전히 반응적입니다. 사용자가 염려하는 한 앱은 더 느리게 시작되는 것처럼 보이지 않아야하며 일단 완료되면 Google 제안 기능이 훨씬 빨라야합니다.

이런 식으로 XML 파일을 쿼리 할 때 인덱스를 사용할 이점이 없으므로 메모리에서조차도 본질적으로 비효율적 인 연산이라고해야합니다. 이것은 full-text searching으로 SQL에서 10 배 빠를 수 있습니다.

물론 XML은 자체 포함되어 추가적인 구성 요소가 필요 없다는 장점이 있습니다. 따라서 소량의 데이터를 쿼리하는 소형 데스크톱 응용 프로그램에 적합합니다. 그렇지 않으면 더 나은 성능을 위해 데이터베이스를 사용하는 것을 고려할 것입니다.

출처

2009-10-09 22:39:43

질문에 온라인 신청을 암시하는 것으로 보입니다.

데이터는/가을 압축해야합니다 수 : 몇 가지 제안이이 경우에 해당. 나는 이것이 매우 잘 압축 될 것이라고 생각한다.
아마도 데이터는 여러 세션에 걸쳐 캐시 될 수 있습니다., 가능하면 만료 캐시 날짜가있는 html 콘텐츠로 제공 될 수 있습니다. 이렇게하면 체계적인로드가 줄어들며 데이터가 자주 업데이트되지 않는 경우 실행이 가능할 수 있습니다. (응용 프로그램이 캐시, 비동기를 초기화하는 동안 ... "로드"즉이 보여주는 말 메시지)
은 제안 기능 기능은 처음을 해제 할 수 있습니다. 이러한 방식으로 제안 기능이 최대 30 초 정도 지연 될 수는 있지만 시작시 응용 프로그램을 신속하게 사용할 수 있습니다.

편집 : 독립적으로 데이터를 다운로드하고이 크기의 XML 파일은 데이터베이스에 대한 빈약 한 대용품이다 미르 Grelus의, 내가 두 번째 의견 캐시됩니다 방법.

출처

2009-10-09 22:41:10 mjv

특히 XML 직렬화가 아닌 바이너리 직렬화를 사용하면 앱이 시작할 때 읽는 데이터를 유지할 수 있습니다. 특히 StringCollection보다 검색 속도가 빠른 데이터 구조를 구현해야하는 경우에는 더욱 그렇습니다. 물론 어딘가에 XML 버전의 데이터를 유지할 수 있습니다.

그리고 언제든지 BackgroundWorker을 사용하여 응용 프로그램의 반응을 느낄 수 있도록 비동기 적으로 데이터를로드하십시오.

출처

2009-10-09 23:36:50

응용 프로그램을 시작할 때 모든 것을 메모리에로드해야합니까?

답변

관련 문제