Anonymous 05/09/20 (Sat) 04:03:22 No. 3444 >>3446
You can pass objects by reference. That's the closest thing to a pointer you can get in Javascript. If you really need to handle pointers directly though, you probably shouldn't be using a highly abstracted scripting language like Javascript and might want to look into using a compiled programming language like C/C++ or Rust.
Anonymous 05/09/20 (Sat) 04:10:11 No. 3446 >>3448
>>3444 Caching idea would be best done with a dictionary hashes going to pointers. The best alternative I can think of is associating ids to hashes and hashes to ids, but waste. At the point where it gets too complicated I think the only node solution is a Redis in memory database. In the least this allows you to go horizontal with it's master slave database thingy
Anonymous 05/09/20 (Sat) 04:23:07 No. 3448
>>3446 >is associating ids to hashes and hashes to ids is associating ids to hashes and ids to caches
Anonymous 05/09/20 (Sat) 04:56:53 No. 3449 >>3450
What are you trying to accomplish? What are the hashes for?
Anonymous 05/09/20 (Sat) 05:07:36 No. 3450 >>3452
>>3449 prevent redundancy when storing data
---
opts = {noimage:true, notext:false, somethingirrelevant:tr
ue}; optshash_1 = hash(opts); console.log(optshash_1); // "101" value_1 = "<p>asdf</p>"; // a very large string opts = {noimage:true, notext:false, somethingirrelevant:false}; optshash_2 = hash(opts); console.log(optshash_2); // "100" value_2 = "<p>asdf</p>"; // a very large identical string store.push({optshash_2:value_2}); store.push({optshash_1:value_1}); // values 2 and 1 are identical yet taking up two memory spaces. // if two clients have different options and are trying to get the same data this is a waste // The alternative prevents redundant information index_store.push({optshash_1:0}); index_store.push({optshash_2:0}); store = [value_1];
Anonymous 05/09/20 (Sat) 05:16:02 No. 3451
>index_store.push({optshash_1:0}); >index_store.push({optshash_2:0}); index_store[optshash_1] = 0; index_store[optshash_2] = 0; because then it's a dict, which was what I was aiming for
Anonymous 05/09/20 (Sat) 05:18:29 No. 3452 >>3454
>>3450 How does the software know the strings are identical? Is there a comparison at some point?
Anonymous 05/09/20 (Sat) 05:30:30 No. 3454
>>3452 The options are the decider for what you get. no Comparision, it's a hash table.
//setting the store
var index_store = {};
var store = [];
function hash(opts){
return "" + (opts.noimage ? 1 : 0) + (opts.notext ? 1 : 0) + (opts.somethingirrelev
an ? 1 : 0); } function storeValue(optshash, value){ index_store[optshash] = store.length; store.push(value); } var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true}); var value_1 = "asdf"; storeValue(opts_1 , value_1); var opts_2 = hash({noimage:true, notext:false, somethingirrelevant:false}); var value_2 = "asdf"; storeValue(opts_2 , value_2); // later evaluation var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true}); function getIfCached(opts){ if(index_store[opts]) return store[index_store[opts]]; } var opts_3 = hash({noimage:false, notext:false, somethingirrelevant:true}); console.log(getIfCached(opts_1)); //asdf console.log(getIfCached(opts_2)); //asdf console.log(getIfCached(opts_3)); //undefined
Anonymous 05/09/20 (Sat) 05:35:41 No. 3457
It's procedural generation of items with a hash table which stores the end result of decisions. The options are the seeds which decide the outcome.
Anonymous 05/09/20 (Sat) 05:38:06 No. 3458
oh shoot, I realize a mistake
Anonymous 05/09/20 (Sat) 05:44:44 No. 3459
I see, you have to make a pretty serious string comparison to save yourself the ram.. --- //setting the store var index_store = {}; var store = []; function hash(opts){ return "" + (opts.noimage ? 1 : 0) + (opts.notext ? 1 : 0) + (opts.somethingirrelevant? 1 : 0); } function storeValue(optshash, value){ var cont = true; for (var i = 0 ; i < store.length ; i++){ if(value == store[i]) { cont = false; break; } } if(cont) store.push(value); index_store[optshash] = store.length - 1; } var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true}); var value_1 = "asdf"; storeValue(opts_1 , value_1); var opts_2 = hash({noimage:true, notext:false, somethingirrelevant:false}); var value_2 = "asdf"; storeValue(opts_2 , value_2); console.log(store.length); // 1 // later evaluation var opts_1 = hash({noimage:true, notext:false, somethingirrelevant:true}); function getIfCached(opts){ if(index_store[opts] != undefined) return store[index_store[opts]]; } var opts_3 = hash({noimage:false, notext:false, somethingirrelevant:true}); console.log(getIfCached(opts_1)); //asdf console.log(getIfCached(opts_2)); //asdf console.log(getIfCached(opts_3)); //undefined
Anonymous 05/09/20 (Sat) 06:10:01 No. 3460 >>3462
A warning: If you use the object-as-dictionary hack, you need to make that none of your keys can ever be any of the following: "constructor" "__proto__" "__noSuchMethod__" "__defineGetter__" "__defineSetter__" "__lookupGetter__" "__lookupSetter__" "hasOwnProperty" "isPrototypeOf" "propertyIsEnumerable" "toLocaleString" "toString" "unwatch" "valueOf" "watch" Or anything else that may get added to the Object prototype in the future, or by software you run. If any of these strings are used as a key, you may get unexpected behavior or even security problems. The key "__proto__" is especially dangerous. Look up "prototype pollution" for examples of the problems it's caused. Alternatively, consider using Map. [If you really need to use objects, Object.create(null) is a solution, but the only reasons I can think of to use that is to create objects for JSON.stringify or to security-patch existing code.]
Anonymous 05/09/20 (Sat) 06:19:37 No. 3461 >>3462
It might be a good idea to remove any known irrelevant options before looking the string up in your cache to prevent the string from needing to be regenerated. (Or the extra code might slow things down; it's something you'd need to test.)
Anonymous 05/09/20 (Sat) 07:21:22 No. 3462
>>3460 Map. Sounds better than an object.
I guess I should add that data is stored as a component_string and a last_used_time. When the cache is filled it's going to boot out the oldest item. This way popular things don't get removed from a cache causing temporary slowdowns and when a googlebot crawls every page it doesn't impact viewers.
>>3461 It's crossed my mind but it's trying to predict the outcome of results when it might not always be black or white.
Anonymous 05/09/20 (Sat) 07:42:44 No. 3464 >>3465
If you want the cache to do you any good, it's probably a good idea to minimize the number of options that can affect the HTML of a post.
Anonymous 05/09/20 (Sat) 08:08:09 No. 3465 >>3467
>>3464 yeah, only the necessary settings are put into a cookie for rendering. I dropped a few things that I didn't think were worthwhile. The 3 cache specific variables of server rendering are embedding thumbnail vs standard embed, Reverse image included or not and post stub, missing(not included) or full post. Even then I could take out the reverse image cookie and put that in localstore. A 200mb cache can hold a lot of 1kb posts.
The other big thing is the sorting type, but posts are cached so it's just a matter of working out client and server to be consistent.
Default mode will be where posts are added as you scroll(infinite scrolling) either in the index or inside of a thread so the server won't die when it hits a 1000 post load that it may or may not have fully cached. A page won't be completely loaded unless a GET flag is set or the user sets the option to be given paged mode. The concept of pages could potentially just vanish unless an archive requests it.
Anonymous 05/09/20 (Sat) 08:16:07 No. 3466
and an update system is going to be another component so the main server can notify the SSR server that it needs to either adjust contents according to the given message. So things like the WiP score counter, ban messages and edits are accounted for so that the server can stay up to date with that,
Anonymous 05/09/20 (Sat) 08:20:06 No. 3467
>>3465 If I were expecting someone to take it to the level of a complete noscript system then someone could potentially cache it all. Every component and build it themselves.
I'd also like people to maybe prefer using a desktop application for kissu(
https://www.electronjs.org/ ) or mobile app(
https://reactnative.dev/) .
So the server side rendering is only one piece of my plan here and things can be done through direct HTTP server messages.
Anonymous 05/11/20 (Mon) 00:07:00 No. 3476 >>12316
wish I was a tech wiz
Anonymous 03/01/24 (Fri) 02:27:53 No. 12316
>>3476 be the change you want to see in the world