讨论串 سلام دوستان
25 条消息 · –P من به شخصه باشم کاری که میکنم اینه که با یک حلقه تمام ردیف ها رو SELECT میکنم و اضافه میکنم به یک لیست. در عین اضافه کردن. یه شرط میزارم. اون شرط اینه که اگر این ردیف قبلا بوده و در نتیجه در لیست هست، این اخری رو پاک کن. If selected in list of selected : اون ردیف رو حذف میکنم. فقط فکر میکنم بهتر باشه Commit رو اخرش انجام بدید.已 P صرفا کنجکاو شدم یه راه حلی به ذهنم اومد نمیدونم چقدر خوبه. ولی فکر کنم هر چقدرم طول بکشه نتیجه رو بده. مثلا مینی بچ های هزار تایی از دیتا بیس رو بگیریم همون کار رو انجام بدیم روی همشون. بعد از هر مرحله مینی بچ هم commit و exit یا حالا هر روش دیگه که رم خالی بشه برای مرحله بعدی تا مینی بچ ها تموم بشه. اینطوری در فاز اول توی هر مینی بچ هر چیزی یکبار وجود داره. حالا هر مینی بچ رو با اون یکی مقایسه میکنیم ببینیم تکراری هست یا نه. در پایان فاز دو حس میکنم نتیجه مطلوب رو داریم. از اونجا که مقایسه A & B مثل B & A هست میشه این حالات رو هم گفت که کلا انجام نده. بستگی داره که رم چقدر بکشه. هر چی بیشتر بکشه مینی بچ ها بزرگتر.S P بله همونطور که گفتم روش عملی خوبی نیست. ولی مشکل رم فکر نمیکنم داشته باشه. چون قبلا چند میلیون بود. الان مثلا صرفا دوتا پنج هزار تایی رو در هر مرحله مقایسه میکنه و رم رو خالی میکنه، برای همین هم گفتم مراحل انجام شده رو توی یک فایل ذخیره میکنیم چون وقتی Quit میکنه اپ بسته میشه متغیر ها هم میپره. یک سوالی که دارم اینه که موقع اجرای یک کد پایتون چه چیزایی توی رم نگه داشته میشه؟ مثلا اگر A = list of million chars باشه بعد A = [1] کنیم فقط دومی توی رم میمونه؟S خب اینجوری که O(n^n هست 😅 و باید هی تکرار شه . .. فک کردم حداقل جمع نتایج هر n مرحله باهمدیگه میخایید با مرحله تکی بعدی مقایسه کنید .. که روش بدی نبود .. و همه تکراری هارو میشد با ۱دور طی شدن پیدا کردن .. ولی خب اخرش (حداکثر کل داده ها (درصورت تکراری نبودن هیچکدوم) و حداقل 70درصد وارد رم میشد) سوال دومتون . بستگی داره اون A چطور خونده بشه .. .مثلا ormهای پایتون اکثرا اعتقاد به lazy-loading دارن .. شما ۱تیبل هرچقد دیتا رو هم بخونید نمیاره تو رم .. تا وقتی که دقیقا بهش دسترسی پیدا کنید با ایندکس یا سعی کنید از حالت query set درشون بیارید .. اما فرض کنید فایل خوندید .. خوندن فایل lazy نیست .. مگر خودتون lazy پیاده سازیش کنید .. و nمگابایت/گیگابایت از یه فایل رو بخونید ..P ایده این بود که هر مینی تا جایی که ممکنه بزرگ باشه. پس اصلا شاید کلا ده تا مینی بچ باشه. خلاصه اینکه نمیشه جمع کنیم چون جمع کنیم ارور رم میده. اگر بشه متغیر ها رو خالی کرد تا رم خالی شه که خود برنامه انجام میده و تموم. اگر نشه، دو راه داره. یا اینکه برنامه در هر مرحله تموم بشه و سیستم عامل هی اجراش کنه با فایل کمکی که بهش میگه از کجا شروع کنه. یه روش دیگه هم هست نمیدونم توی پایتون میشه انجام داد یا نه. توی متلب دو تا فایل کد رو توی یک دایرکتوری میزاشتیم، به داده های هم دسترسی داشتن. در این صورت اگر مثل متلب باشه، میشه دوتا کد برادر و مشابه نوشت که هر کدوم در اخر ارجاع میده به داداشش.S اون اخری رو نفهمیدم متلب و داداش چیکار کرد 😂 مشکل سر O(n^n هست .. و کندی پروسس .. هر مینی بچ باید با تمام بچ های دیگه مقایسه بشه .. .همین .. راه بهینه ای نیست . ...ذخیره نتیجه هم کمکی به پروسس مینی بچ های بعدی نمیکنه .. فقط مقایسه هر مینی بچ با بقیه هست که میتونه بصورت تضمینی داده های تکراری شو ازش در بیاره .. .و در نهایت بصورت تمیز ذخیرش کنه . ..P S
Y
S
已